VCS comparison table

Jakub Narebski jnareb at
Wed Oct 18 10:07:34 BST 2006

Andreas Ericsson wrote:
> Aaron Bentley wrote:
>> Well, there's distributed, and then there's *DISTRIBUTED*.  We don't
>> quasi-randomly merge each others' branches.  We have a star topology
>> around  So when we refer to revnos, they're usually in
> So in essence, the revnos work wonderfully so long as there is a central 
> server to make them immutable?
> Doesn't this mean that one of your key features doesn't actually work in 
> a completely distributed setup (i.e., each dev has his own repo, there 
> is no mother-ship, everyone pulls from each other)?
> I can see the six-line hook that lays the groundwork for this in git 
> before me right now. I'll happily refuse to write it down anywhere. I 
> get the feeling that sha's are easier to handle in the long run, while 
> revno's might be good to use in development work. In git, we have 
> <branch/tag/"committish">~<number> syntax for this.
> In my experience, finding the revision sha of an old bug is what takes 
> time. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly 
> now, do you actually remember the revno for a bug that you stopped 
> working on three weeks ago, or do you have to go look it up? If someone 
> wants to notify you about the revision a bug was introduced, do they not 
> communicate the revno to you by email/irc/somesuch?

Revnos were supposed to be superior to using sha1 (or shortened sha1)
as commit identifiers because of two key features:
 1. They were simplier than sha1, therefore easier to use
 2. Given two revisions related by lineage (i.e. one is ancestor of
    the other) you can from a glance know which revision was earlier

But the details invalidated 1.: for complicated history, for a large
project, with many contributors and nonlinear development we have vs 988859a (7 chars shortcut of sha1)
to have immutable revno. And we have to use _immutable_ (up to few
years) revison identifiers, unless we want our "simple ids" scheme
to make a mess...

And I'm not sure if 2. is true, if even for revisions with direct
lineage we don't have to compare with for
example. Having generation number would solve 2.; as of now git
check for fast-forward case by checking if merge-base of two
revisions is one of the revisions.
Jakub Narebski

More information about the bazaar mailing list