On Wed, 18 Oct 2006, Carl Worth wrote:
>
> 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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
and here's a BK "ChangeSet Key":
adi@xxxxxxxxxxxxxxxxxxx|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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html