On Sun, Jul 20, 2008 at 01:09:59PM -0700, Lan Barnes wrote:
p4's change sets aren't change sets? I'm interested. How not?
It depends on how you define a change set. They are atmoic and group commits that are logically oriented within the depot. However, their existence seems to have been forgotten by much of the rest of P4. Labels tag individual file versions, and often don't correspond with a single changeset at all.
p4 lets you rearrange directory trees (alas, empty dirs need a stub to stay alive). Again, am I missing something? p4 is a branch-on-checkout and does support branches. I'm _sure_ of that.
P4 supports a very limited notion of branch, similar to the branch by copying notion of SVN. It very much is not branch-on-checkout, and must be an explicit step done that changes the name of the entity in the repo. This merely makes them expensive and inconvenient. The reason I don't call them real branches is that P4 only tracks branches on a per file basis (again completely forgetting about change sets). This tends to work reasonably well for branches that don't differ much, don't live all that long, and are then integrated back into the mainline. Long lived branches, where lots of changes happen, become more and more difficult to manage and integrate. That branch names and directory names share the same namespace means that P4 can't tell the difference between a file rename and a branch. So, if you have branched a tree that has renames in it, you basically have to track down what happened, and "do the right thing", for every single file.
Methinks I'm misinterpreting something. Did you mean svn rather than p4?
Hard to say :-) P4 and SVN share so much of the same bad design. I suspect that P4 had a lot of influence on the SVN design, but people don't want to say that. David -- KPLUG-List@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
