[p4] How does Bitkeeper compare to Perforce?

[Robert Cowham]

> > 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.


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.

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.

One point of view on the distributed model is:

http://www.rockstarprogrammer.org/post/2007/may/14/using-mercurial-work-arou
nd-centralized-scm-limita/

This guy seems a little extreme, but it's a point of view...

Robert