[p4] Codelines and Components
matt.craighead at conifersystems.com
Thu Nov 20 13:15:55 PST 2008
> My understanding is that the copy-on-write semantics make branching very
It would be nice if this were true, but unfortunately Perforce branching is
not as cheap as Perforce's marketing materials suggest.
Branching a tree in Subversion is O(1), no matter how many files are in the
tree. As you commit changes to the branch, the nodes are subdivided. The
eventual cost of a branch is roughly proportional to the number of files you
edit inside the branch.
Branching a tree in Perforce is O(number of files in the tree). The size of
the files doesn't matter, but the total number of files matters. It has to
create a new database record for each file branched, even if you have no
intention of ever modifying that part of the tree in the branch. The basic
problem is that Perforce does not track "directories" as first-class
concepts, so it can't refer to an entire directory tree of files "by
reference" -- it has to populate the tree all the way down.
Still, even with this cost, I lean towards the //depot/main/component model.
On Thu, Nov 20, 2008 at 2:50 PM, Roy Smith <smith_roy at emc.com> wrote:
> On Nov 20, 2008, at 2:52 PM, David Ferguson wrote:
> My objection to the //depot/main/component is fundamentally one of
>> branching expectations. That policy tends to drive people toward branching
>> all components every time any of them branch.
> Is that a problem? I always branch the whole project. My understanding is
> that the copy-on-write semantics make branching very low cost, so why not
> branch it all? It sure beats branching just one component and then
> discovering later that you really needed to branch some other component and
> have to go back and branch it too, etc
> Roy Smith <smith_roy at emc.com>
> Software Guy, EMC
> 1133 Westchester Ave, 3rd floor
> White Plains, NY 10604
> +1 914 461 3597
> AIM: roysmith649
Founder/CEO, Conifer Systems LLC
More information about the perforce-user