On Thu, Oct 19, 2006 at 11:09:49PM -0300, Horst H. von Brand wrote:
> Jan Hudec <bulb@xxxxxx> 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.
As they currently are you can't either. Because currently it is
guaranteed that the revnos will be the same in two branches with the
same current revision. But when the current revisions differ, the
numbers may as well.
Moreover currently they can change for the same branch over time, while
with the alternate proposal they would not, so you could reliably say
revision 567 on foo.
> > - 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.
1) Partial sha-1 is still longer (starts being useful at 6 digits,
usually you need 8)
2) Decimal numbers are easier to remember than hexadecimal ones.
3) The hashes are not oredered.
> > - 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.
That's however separate issue. Negative numbers are tip-relative and
there are various prefixes in bzr (like before:, ancestor: etc.) for
relative revision addressing.
> > - This is more than the current scheme can give, since now pull can
> > renumber revisions.
>
> Urgh. Get an update, and all your bearings change?
Currently yes. Currently pull changes the branch to be a mirror of the
pulled-from branch, including the way they are numbered.
> > - They wouldn't make any branch special, so the objections Linus raised
> > does not apply.
>
> But the original branch /is/ special?
Some branches are usually special, but which they are may not
necessarily coincide with the left-parent lineage.
> > - 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
Did you notice that I also said svk and mercurial? They both *ARE*
distributed (well, svk has it's limitations, but mercurial really very
similar to git).
> history, and they are intertwined.
>
> Not at all useful.
There are no global persistent revision numbers in a distributed system.
There can't be. But numbers with limited scope can still be really
useful. The question is what that scope should be.
--------------------------------------------------------------------------------
- Jan Hudec `Bulb' <bulb@xxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html