[p4] How does Bitkeeper compare to Perforce?

[Andrew May]

On Wed, 4 Jul 2007 15:40:03 +0100
"Robert Cowham" <robert at vaccaperna.co.uk> wrote:

> > > The spin on true facts is also pretty major, for example:
> > > "Perforce loses information every time there is parallel
> > > development 
> > because you 
> > > are forced to merge before you check in if someone else checked
> > > in first."  That's a *good* thing! =)
> > 
> > I really see it as a very bad thing. There are times where I 
> > do a change and build/test it and it works. Then someone else 
> > checks in a change. When this happens to me I usually end of 
> > doing a manual copy of my current code changes (just in case, 
> > to make up for the lack of recorded history). Then go through 
> > the merge and build/test to see how things work compared to 
> > my last build/test.
> > And if there are any failures I have to go back to my manual 
> > copy to see where the merge went wrong. And there is no 
> > history of this in-between step, in case the tests do pass, 
> > but there is some obscure merge problem that is hidden until 
> > even more testing is done.
> 
> I commented on this in the article:
> 
> Branching and Merging - An Agile Perspective
> http://www.cmcrossroads.com/content/view/6657/202/
> 
> Note the case study where this came up "Case Study - Branch on
> Conflict" towards the end.
> 
> Personally I would look to script this for Perforce if it was an
> issue for me - it is very similar to the idea of shelving.

Yes, that is a good example of the problem. And it doesn't hit me
enough for me to want to script it either.

As your article describes it is possible to deal with the problem, but
first you even know the problem is there. And the standard perforce
checkin doesn't even provide any info that the problem has already
occurred.

But going back to the term "atomic", and with my example where there
are 2 dependent files, each one changed by a different user in a
incompatible way.
If both users submit the files at about the same time, and without
having a sync in-between. This possible in Perforce (and sometimes even
helpful), but this is where perforce fails to "atomically" catch these
operations as being separate.
You now have the head of the repo, with file1.c#2 and file2.c#2, that
have never been built or tested together at those versions.
Only file1.c#2 with file2.c#1, and file1.c#1 and file2.c#2 were ever
tested by the developers.
I guess you could write a submit trigger that checked the
changelist number from //...#have against //... and reject the change
if the user isn't up to date with all files. The question is if this
would be an atomic operation? I am not sure if the triggers provide
that.


> I have lots of respect for the technical capabilities of BitKeeper,
> but I do think that many corporations prefer to keep their assets
> more controlled.

Yes it can be a bit scary to think a single disgruntle employee could
walk out with an entire company source history on a single flash drive.

For the control of files, it may be better to think of the source
control as any other set of networked files, on a common file server.
It could be a local policy to force all the clones to be restricted to
a common backed up file server, with ACL control and audit recording.
 
> Of interest to me is the growth of open source distributed tools
> (Darcs/Mercurial/Bazaar/Git) and their usage, but I am not really
> sure about their applicability in many corporate environments.

SVK is yet another option, but I haven't had much luck with it yet.