Re: Alternate revno proposal (Was: Re: VCS comparison table)
- From
Horst H. von Brand <vonbrand@inf.utfsm.cl>
- Date
- Oct 20, 2006, 02:09 UTC
- Message-ID
- <200610200209.k9K29ncC006935@laptop13.inf.utfsm.cl>
- In-Reply-To
- <bulb@ucw.cz>
Jan Hudec <bulb@ucw.cz> wrote:
[...]
Show 9 quoted lines
> 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.
Show 6 quoted lines
> - 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.
Show 9 quoted lines
> - 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?
Show 6 quoted lines
> - 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