VCS comparison table

[Andreas Ericsson]

Matthew D. Fuller wrote:
> On Wed, Oct 18, 2006 at 08:38:24AM -0700 I heard the voice of
> Carl Worth, and lo! it spake thus:
>> But as you already said, it's often avoided specifically because it
>> destroys locally-created revision numbers.
> 
> I think this has the causality backward.  It's avoided because it
> changes the ancestry of the branch in question, by rearranging the
> left parents; this ties into Linus' assertion that all parents ought
> to be treated equally, which I'm beginning to think is the base
> lynchpin of this whole dissension.
> 
> 
> Without a differentiation of the parents, there's no such creature as
> a "mainline" on a branch, so it's hard to find anything to base revnos
> on from the get-go; the whole discussion becomes meaningless and
> incomprehensible then.
> 
> With the differentiation, numbering along the leftmost 'mainline'


You, and others, keep saying "leftmost". What on earth does left or 
right have to do with anything? Or rather, how do you determine which 
side anything at all is on?

> makes sense, and fits the way people tend to work.  "I did this, then
> I did this, then I merged in Joe's stuff, then I did this", and the
> numbering follows along that.  And as long as it's the same branch,
> those revnos will always be the same; I can't go back and add
> something in between my first and second commits.  THAT'S where revnos
> are useful; referring to a point on given branch.
> 

So long as the given branch is, in git-speak, "master"? I think I'm 
starting to see how this would work, but I still fail to see how you can 
then come up with revnos such as 2343.1.14.7.19, since the only ones 
that seem to actually make any sense are the ones that track the 
strictly linear development.

In git, this can be accomplished by auto-tagging each update of any 
branch with a tag named numerically and incrementally, although no-one 
really bothers with it.

Let's say you have the following graph, where A is the root commit, B 
introduces the base for a couple of new features that three separate 
coders start to work on in their own repositories. The feature started 
on in D is logically coded as a two-stage change. F fixes a bug 
introduced in D. I is the result of an octopus merge of all three 
branches, where the three features are implemented and all bugs are 
fixed (this is btw by far the most common pattern we have in our repos 
here at work).

   A
   |
   B
  /|\
C |  D
| |  |\
| |  E F
| |  |/
| |  G
| H /
  \|/
   I

Now a couple of questions arise.
- How do I do to get to C, D, E, F, G and H?
- When these get merged, which one will be considered the "left" parent, 
and why?

> 
>> So there are some aspects of the bzr design that rob from its
>> ability to function as a distributed version control system. It
>> really does bias itself toward centralization, (the so called "star
>> topoloogy" as opposed to something "fully" distributed).
> 
> That depends on what you mean by 'bias' (and for that matter, what you
> mean by 'centralization'; I think that's being used in very different
> ways here).  If you don't care about the ancestry changes, you can go
> ahead and change it around by merging and pushing like there's no
> tomorrow, and it'll keep up just fine.  Some attributes of it like the
> revnos which assume you do care about the ancestry simply cease to be
> of any applicability.


How deep will I have to dig to get the immutable revids instead?


>  That doesn't make it a useless feature, any
> more than diff being inapplicable in a branch I'm using to store
> binary files makes diff useless; it's just not one that's meaningful
> in a given case.
> 

Binary diffs work just fine, thank you very much ;-)

> bzr (the project) does care about the ordering of the parents, so it
> doesn't do that.  bzr (the tool) assumes that the majority of its
> users will care, which is why it has revnos; because in the case where
> you don't disturb the ancestry of given branches, revnos are very
> useful in reference to that branch.
> 
> 
>> So even a project that's very oriented around a single, central tree
>> can get a lot of benefit from being able to share things arbitrarily
>> between any two given repositories.
> 
> I agree wholeheartedly.  That's one of the reasons I'm using bzr, even
> though 95% or better of what I do is very oriented around single,
> central trees, after all    8-}
> 

I'm sure it's supported. The question is whether or not bazaar makes it 
easy for those developers to exchange valuable information (revids, 
since their revnos will be mixed up) so they can communicate detailed 
info about "commit X introduced a bug in foo_diddle(). I fixed it in 
commit Y, so if you merge it we can release". If revids are always 
printed anyways, I see even less need for revnos. If it's hard to get 
the revids I wouldn't consider the truly distributed workflow supported 
any more than I consider CVS file rename support á la "just hand-edit 
the ,v-files" to actually work.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231