Re: VCS comparison table

From: Linus Torvalds <torvalds@osdl.org>
Date: Oct 19, 2006, 15:25 UTC
Message-ID: <Pine.LNX.4.64.0610190757100.3962@g5.osdl.org>
In-Reply-To: <87lkncev90.wl%cworth@cworth.org>

On Wed, 18 Oct 2006, Carl Worth wrote:

Show 5 quoted lines

> 
> I understand that bzr also has unique identifiers, but it sounds like
> the tools try to hide them, and people aren't in the habit of using
> them for things like this. Do bzr developers put revision numbers in
> their bug trackers? Is there a guarantee they will always be valid?

bzr seems to use the classic UUID format, and it's funny how much it looks like a real BK ChangeSet revision number ("key").

Here's the quoted bzr "true" revision ID:

	Matthieu.Moy@imag.fr-20061017152029-4c5a2861bcf23b7d

and here's a BK "ChangeSet Key":

	adi@zaphod.bitmover.com|ChangeSet|20031031183805|57296

(I don't have BK installed anywhere, so I had to google for changeset keys, and this was just some random key in the BK bugzilla ;)

Looks very similar, don't they? And yes, the true revision ID is stable over time (at least it was in BK, and I assume it is in bzr too).

The biggest difference seems to be that in bzr, the final checksum is 64-bit, while for BK, it was just a 16-bit checksum/unique number (the rest is just user-name/machine-name and date: I assume that the bzr commit was done at 10/17/2006 3:20:29PM, and the example BK ChangeSet was created 10/31/2003 6:38:50PM - it looks like _exactly_ the same date format).

With BK, you can also use a "md5 key", and I don't actually know how they work. They may just be the md5 hash of the ChangeSet key, I think that may be how those things are indexed. So in bkcvs, you'll see a line like this:

	BKrev: 42516681VmgTWL0bkLcltPGiI6Yk5Q

which is the BK md5 key for my last kernel revision in BK (2.6.12-rc2). Again, these numbers are stable, unlike the simple revisions.

Note that from a usability standpoint, the UUID's look more readable to a human, but are actually much worse than the md5 keys (or the SHA1's that git uses). At least with a hash, the first few digits are likely to be unique, so you can do things like auto-completion (or just short names). With the email+date+random number kind of UUID, you don't have that.

(Pure hashes obviously also tend to just all have the same length, and are easier to parse automatically, so from a programmatic standpoint they are a lot easier too - but the surprising thing is how they are actually easier on humans too, even if the UUID's look more readable).

			Linus