Subject: Re: VCS comparison table

From: Aaron Bentley <[email-masked]>
Date: Tue, 17 Oct 2006 01:08:59 -0400

Johannes Schindelin wrote:
> On Mon, 16 Oct 2006, Aaron Bentley wrote:

>> Bazaar's namespace is "simple" because all branches can be named by a 
>> URL, and all revisions can be named by a URL + a number.
> 
> How should this cope with a distributed project? IOW how does it deal with 
> "this revision and that revision are exactly the same"?

There are two answers here.  One is that the URL + number is UI, not
internals.  A unique ID is used internally, so that can be compared.

But to fully ensure that there are no differences, i.e. that no one has
reused an ID, you can generate a revision testament.

> If I understand you correctly, you are claiming that you are not really 
> identifying a revision, but a revision _at a certain place with a 
> place-dependent number_. This conflicts with my understanding of a 
> revision.

No, I am claiming that a revision at a certain place with a
place-dependent number is one name for a revision, but it may have other
names.

>> If that's true of Git, then it certainly has a simple namespace.  Using 
>> eight-digit hex values doesn't sound simple to me, though.
> 
> It depends on your usage. If you want to do anything interesting, like 
> assure that you have the correct version, or assure that two different 
> person's tags actually tag the same revision, there is no simpler 
> representation.

I can use the 'bzr missing' command to check whether my branch is in
sync with a remote branch.  Or I can use the 'pull' command to update my
branch to a given revno in a remote branch.

>> That sounds right.  So those branches are persistent, and can be worked
>> on independently?
> 
> Of course! Persistence (and reliability) are the number one goal of git. 
> Performance is the next one.

You'd be surprised.  When we last spoke to the Mercurial team, Mercurial
didn't support multiple persistent branches in one repository.  Pulling
from a remote repository could join two branches into one.  I'm told
they're fixing that now.

>> You'll note we referred to that bevhavior on the page.  We don't think
>> what Git does is the same as supporting renames.  AIUI, some Git users
>> feel the same way.
> 
> Oh, we start another flamewar again?

I'd hope not.  It sounds as though you feel that supporting renames in
the data representation is *wrong*, and therefore it should be an insult
to you if we said that Git fully supported renames.

Aaron