Alternate revno proposal (Was: Re: VCS comparison table)

[Horst H. von Brand]

Jan Hudec <bulb at ucw.cz> wrote:

[...]

> Reading this thread I came to think, that the revnos should be assigned
> to _all_ revisions _available_, in order of when they entered the
> repository (there are some possible variations I will mention below)
> 
>  - Such revnos would be purely local, but:
>    - Current revnos are not guaranteed to be the same in different
>      branches either.
>    - They could be done so that mirror has the same revnos as the
>      master.

Then they are almost useless (except for people working alone). You need to
be able to talk about a particular commit with others working independently.

>  - They would be easier to use than the dotted ones. What (at least as
>    far as I understand) makes revnos easier to use than revids is, that
>    you can remember few of them for short time while composing some
>    operation. Ie. look up 2 or 3 revisions in the log and than do some
>    command on them. And a 4 to 5-digit number like 10532 is easier to
>    remember than something like 3250.2.45.86.

Probably. In git you can (mostly) get away with partial SHA-1's, BTW.

>  - Their ordering would be an (arbitrary) superset of the partial
>    ordering by descendance, ie. if revision A is ancestor of B, it would
>    always have lower revno.
>    - The intuition that lower revno means older revision would be always
>      valid for related revisions and approximately valid for unrelated
>      ones.
>  - They would be *localy stable*. That is once assigned the revno would
>    always mean the same revision in given branch (as determined by
>    location, not tip).

Tip-relative is extremely useful: I wouldn't normally remember the current
revision, but I'll probably often be talking about "the change before this
one" and so on.

>      - This is more than the current scheme can give, since now pull can
>        renumber revisions.

Urgh. Get an update, and all your bearings change?

>  - They wouldn't make any branch special, so the objections Linus raised
>    does not apply.

But the original branch /is/ special?

>  - They would be the same as subversion and svk, and IIRC mercurial as
>    well, use, so:
>    - They would already be familiar to users comming from those systems.
>    - They are known to be useful that way. In fact for svk it's the only
>      way to refer to revisions and seem to work satisfactorily (though
>      note that svk is not really suitable to ad-hoc topologies).

SVN is /centralized/, there it does make sense talking about (the one and
only) history. In a distributed system, potentially each has a different
history, and they are intertwined.

Not at all useful.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513