Muli Ben-Yehuda's journal

July 1, 2005

Happy No-BK day!

Filed under: Uncategorized — Muli Ben-Yehuda @ 10:58 AM

Of the two projects I care about that were using BK, one is using git and also has a mercurial tree, and the other is using mercurial. Time to dive into hg


  1. BitKeeper? We don’t need no stinkin’ BitKeeper!

    It’s a good thing to know that Xen has switched to an open-source solution instead of BitKeeper. However, this is the first time I heard of Mercurial, or at least recall knowing about it. There seems to be an inflation of open-source version control systems lately: Subversion, tla, ArX, Bazaar, Bazaar-NG, darcs, git/cogito, Mercurial, Codeville, svk, Vesta, Monotone, Superversion, FastCST, Bky, Meta-CVS/HO-CVS, DCVS, OpenCM, etc. etc. I have no idea why so many are required, or why the developers of the (N+1)’th system where unhappy with systems 1 through N.

    In any case, now I wonder what MySQL will choose instead of BitKeeper. They don’t seem to make a heavy use of the distributed nature of BK, so they may choose Subversion. (possibly with some help from svk).

    Comment by shlomif — July 1, 2005 @ 10:39 AM | Reply

    • Re: BitKeeper? We don’t need no stinkin’ BitKeeper!
      The reason why there are so many revision control systems is probably that many of them were developed in parallel.
      Of course, Real Programmers don’t need no steenkin’ revision control system! :-B
      — bi (

      Comment by Anonymous — July 1, 2005 @ 11:25 AM | Reply

      • Re: BitKeeper? We don’t need no stinkin’ BitKeeper!

        Actually, many of the VCSes (= Version Control Systems) I mentioned were developed some time after there was a lot of well-established alternatives.

        Comment by shlomif — July 1, 2005 @ 1:27 PM

  2. what do you think of Mercurial?
    (all anonymous postings are from me. forgot to login)

    Comment by Anonymous — July 2, 2005 @ 7:16 AM | Reply

    • I like it so far, certainly more than I like git. This is based on just playing with it, though, haven’t looked at the code at all yet.

      Comment by mulix — July 2, 2005 @ 10:21 AM | Reply

  3. SHA1
    Both git and hg use SHA1 for integrity checks. They basically assume that the chances of two different items generate the same checksums is negligible.
    Do they rely on it anywhere? Is there anything to gain from generating a data item with the same SHA1 sum as a different item? There seem to be signs that finding such a hash is not as difficult as we originally thought.
    If so: what would it take to replace SHA1 with a different hashing method? It would certainly be a serious change to the storage format, wouldn’t it?

    Comment by Anonymous — July 4, 2005 @ 1:52 PM | Reply

    • Re: SHA1
      Q. What about hash collisions? What about weaknesses in SHA1?
      The SHA1 hashes are large enough that the odds of accidental hash collision are negligible for projects that could be handled by the human race. The known weaknesses in SHA1 are currently still not practical to attack, and Mercurial will switch to SHA256 hashing before that becomes a realistic concern.
      Collisions with the “short hashes” are not a concern as they’re always checked for ambiguity and are still long enough that they’re not likely to happen for reasonably-sized projects (< 1M changes).

      Comment by mulix — July 4, 2005 @ 2:35 PM | Reply

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: