VCS comparison table

[Linus Torvalds]

On Tue, 17 Oct 2006, Robert Collins wrote:

> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:
> > 
> >           ---- time --->
> > 
> >     --*--*--*--*--*--*--*--*--*-- <branch>
> >           \            /
> >            \-*--X--*--/
> > 
> > The branch it used to be on is gone...
> 
> In bzr 0.12 this is :
> 2.1.2
> 
> (assuming the first * is numbered '1'.)
> 
> These numbers are fairly stable

And here, by "fairly stable", you really mean "totally idiotic", don't 
you?

Guys, let's be blunt here, and just say you're wrong. The fact is, I've 
used a system that uses the same naming bzr does, and I've used it likely 
longer and with a bigger project than anybody has likely _ever_ used bzr 
for.

It sounds like bzr is doing _exactly_ what bitkeeper did. 

Those "simple" numbers are totally idiotic. And when I say "totally 
idiotic", please go back up a few sentences, and read those again. I know 
what I'm talking about. I know probably better than anybody in the bzr 
camp.

Those "simple" numbers are anything but. They may be short, most of the 
time, but when you bandy things like "-r 56" around, what you're ignoring 
is that for a _real_ project you actually get numbers like "1.517.3.57", 
which isn't really any simpler or shorter than saying "7786ce19". You 
still want to cut-and-paste it.

And the "simple" numbers have a real downside, which is that THEY CHANGE.

What happens is that somebody else started _another_ branch at revision 2, 
and did important work, and and they also had a "2.1.2" revision, and then 
they merged your work, and you merged their merge back, that "simple" 
revision number changed, didn't it? Suddenly "2.1.2" means something 
different for one of the users.

We had people in the bitkeeper world that _never_ actually understood that 
the numbers changed. The "simple" numbers were stable enough that a lot of 
people thought they were real revisions, and then they were really 
_really_ confused when a number like "1.517.3.57" suddenly went away after 
a merge, and became something else instead.

And yes, bitkeeper had a "real key" internally too. If you actually wanted 
to give a real revision, you had to give something that looked a lot like 
what the bzr internal revision numbers look like.

Of course, most users didn't even _know_ or understand those revision 
numbers, so as a result, you had tons of people who used the "simple" 
thing (which was what "bk log" and all other tools would show), and since 
it worked quite often, they thought it was ok. And then sometimes it 
didn't work at all, or it "worked" by giving the wrong commit, and it was 
just a total disaster.

Something that works "most of the time" is not simple to use. It's just a 
way to make people _believe_ it is simple, and then be really confused 
when it doesn't work.

So trust me, naming things so that the name depend on the local shape of 
the history is idiotic. I _know_. Been there, done that.

The thing is, when I designed git, I actually had years of experience 
working with a big project in a truly distributed manner. I _knew_ that 
handling renames specially is a bad idea (not that you should even need to 
have used BK to know that).

And I _knew_ that the simple revision numbers aren't real and just cause 
confusion.

			Linus