[p4] How does Bitkeeper compare to Perforce?

[Andrew May]

On Tue, 03 Jul 2007 08:54:17 -0500
Ken Williams <ken.williams at thomson.com> wrote:

> Hi Jeremy,
> 
> That comparison is woefully misinformed.  It claims Perforce doesn't
> even have atomic changesets!

It has been awhile since I used bitkeeper, and I don't know about there
comparison list.

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

And for changes to things like the rules what needs to lock between
functions, the history of where the change was first made is very
important. Since the locking change may not result in an actual merge
conflict.

ie.
I change func1 in file1.c to get some data that needs a lock.
Where in main.c func1 is being called with the lock held.

Then person 2 changes and checks in main.c to remove the lock hold,
since to them func1 doesn't need the lock. 

Now I can still check in file1.c without even a sync since person 2 only
touched main.c.

Now person3 that does a sync to head, gets a copy of the new file1.c
and main.c, that no-one has even built or tested.

It may be a long time for a source control tool to actually alert you
to the possible "merge" problem because of the lock change.
But it should at least be able to track that this combination of
main.c and file1.c have never been used together.

> As I'm sure someone else will reply too, the major difference between
> BitKeeper and Perforce is that distributed repository means
> centralized merging, but centralized repository means distributed
> merging.  If you want some central gatekeeper person to have to do
> all merges, BitKeeper can work in your organization, but IMO it

This is not true at all. You can have any number of people do the
merges, and they can each in turn do the "pull/merge/push" to common
main repository. 

There is the Linux/Linus model where Linus is the centralized merger
(that never does a push), but he tries to just do simple merges. But the
complex merge conflicts are resolve by all the other people doing the
actual changes.

> doesn't work well in the traditional model of development teams.

Yes that is the biggest hurdle to get over. But tradition doesn't make
something right or the best. The Peer to Peer model is something to
get use to, but it does have many advantages. Just being able to have
the full history locally for a disconnected laptop, is a big enough
seller for the Peer to Peer model for me. 

The bitkeeper site still has the link on the "double-the-pace" story,
even after the big Linux fallout.
http://www.theage.com.au/news/Soapbox/Crunch-time-for-Linus/2005/04/14/1113251731624.html

"BitKeeper has made me more than twice as productive, and its fundamentally distributed nature allows me to work the way I prefer to work - with many different groups working independently, yet allowing for easy merging between them."

After that Linus wrote git just to replace what bitkeeper was doing for
him.