Reply to post: Re: Doesn't surprise me

Splunk: Why we dumped Perforce for Atlassian's Bitbucket of Gits

stephanh

Re: Doesn't surprise me

This is in fact a normal way of working for Perforce. Let me explain.

Perforce is philosophically derived from the RCS/CVS lineage. RCS operates on single files and just keeps a sequence of revisions to that single file. CVS is kind of a hack around RCS to introduce the weird notions that your project might consist of more than one file and that sometimes you might even want to "branch", i.e. not have a linear progression of versions. However fundamentally things are still tracked at a per-file level.

This makes it fundamentally very easy to check out a subset of the files of your project, since the files are in some sense all quite independent. So you *can* have a single repository which contains all different products of your company.

The reason you will *want* to is because $DEITY help you if you ever want to share some code between projects which are NOT using the same repository. Probably best to merge the projects into a single repository then, so better start with a single repository in the first place.

So not only is Perforce a centralised version control system in that it encourages a single repository per project, it encourages in fact A Single Repository *period*.

In contrast, Git tracks changes on a complete repository basis and doesn't deal with changes to individual files. While doing a partial checkout ("sparse checkout") is possible in Git, it is really not recommended. So Git strongly "encourages" you to split your repository in more manageable parts.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021