VCS comparison table

[Erik Bågfors]

On 10/24/06, Martin Langhoff <martin.langhoff at gmail.com> wrote:
> On 10/24/06, Linus Torvalds <torvalds at osdl.org> wrote:
> > On Tue, 24 Oct 2006, Erik Bågfors wrote:
> > >
> > > I don't see any problem doing a "gitk --all" equivalent in bzr.
> >
> > The problem? How do you show a commit that is _common_ to two branches,
> > but has different revision names in them?
>
> Eric,

It's Erik :)

> coming from an Arch background, I understand the whole per-branch
> commitids approach. After using GIT for a while, you start realising
> that it tries to pin down things in the wrong place.
>
> This is specially visible if you run `gitk --all` before and after a
> merge. Or on a project with many merges (if you can, get a checkout of
> git itself, and browse its history with gitk).
>
> Before the merge, you see
>
>  --o--o--o--o
>     \
>      \--o--o
>
> and after
>
>  --o--o--o--o
>     \        \
>      \--o--o--o
>
> Now, after it's merged somewhere, both commits are part of its
> history, regardless of where they come from. And it is very clear if
> two branches have been merging and remerging.
>
> Where a commit originated does not matter. And fancy
> repo-and-branch-centric names get in the way. A lot. And they re
> mostly meaningless as soon as you put what matters in the commit
> message. Which means that that bit of metadata that you are hoping
> that the revno keeps "indirectly" isn't lost on cherry picking.

Let's make one thing clear.  Revnos are NOT stored with the revision,
they are not "names" of the revision.  They are basically just
shortcuts to specific revisions, that only makes sence in the context
of a branch.

As human beings this is something we are very used to in everyday
life. I don't always call my friends with firstname and surname, I
just use first name or even "mate".  As long as it's clear who I'm
talking about in that contect.  If there are multiple people with the
same first name, then we might have to use the surname as well.

Same with bzr. In the context of a branch, revnos works as shortcuts
to the revision id.  In the context of multiple branches, they don't.

I think they do serve a good purpose but I don't really think that we
absolutely need them either.

> I guess that's where I used to find revnos useful as they contained
> some basic metadata. With bzr it seems to be author-repo-branch where
> branch is hopefully "line of work" but all of that can be (and should
> be) in the commit message.
>
> You can see similar info in the first part of the commit message for
> most git-hosted projects. It'll say something like
>
>    cvsserver: fix the frobnicator to be sequential
>
> which means that at that point, you could be working in a branch
> called fix-this-fscking-thing-attempt524" and no-one would know ;-)
>
> And in a few years (even months) time, that bit of metadata you were
> hoping to keep is totally irrelevant. What you have in the commit
> message remains relevant and useful.

I'm not even going to try to understand the argument here as they are
about a totally different thing and doesn't make any sense to me.

I think this disussion is getting out of hand.

There are a few things that are being discussed
1. Revnos are bad/good
2. treating "leftmost" parrent special is bad/good
3. plugins are useless/useful
4. And now, storing branch information should be done manually (if
wanted) and not automatically.

1. I don't really care, I haven't seen any confusion based on it, but
I don't have a very strong opinion about it either.
2. This is something I do care about.  For me, this is the only
logical way of doing it. It might be because I am used to it now, but
when I started to look at bzr/hg/git/darcs/etc, I just got a so much
more clear view of the history when running a standard log command,
that it was one of the first things that attracted me to bzr. This is
just a user talking.
There might be technical reasons why it's better to not do it, but for
me it works the way I expect, therefore I'm happy
3. This is just silly
4. No comment.

/Erik