On Wed, Oct 18, 2006 at 03:26:40PM +1000, Robert Collins wrote:
> revnos visibly change as your work is merged into the mainline - we've
> been doing this for years without trouble: ones own commits to a branch
> get '3', '4', '5' etc as revnos, and when they are merged to the
> mainline they used to stop having revnos at all, but now they will be
> given this dotted decimal revno. If you pull from the mainline after the
> merge, you see the new numbers, and when you look at mainline you can
> see the difference. So while I agree that the surprise the user gets is
> inversely related to the frequency with which they see the behaviour, I
> think our users see it a lot, so are not surprised much.
>
> FWIW, we're not optimising for mostly straight histories as I understand
> such things : our own history has 3 commits on branches to every one on
> the mainline.
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.
- 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.
- 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).
- This is more than the current scheme can give, since now pull can
renumber revisions.
- They wouldn't make any branch special, so the objections Linus raised
does not apply.
- 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).
Now I said there are two options how to assign them. These are:
- Repository-wide: Number would be assigned to each revision entering
the repository, even when it is not in ancestry of any branch (ie.
if one starts a merge, but than reverts it).
- Advantages:
- Simpler to implement (just log every written-out revision).
- All branches in the same repository use the same revision
numbers, so if you keep branches in a shared repo, it makes
easier to look up one revision in log of one branch, other in log
of other branch and run diff on them.
- Disadvantages:
- Mirror only has the same revnos if both master and the mirror are
stand-alone branches.
- Branch-wide: Nuber would be assigned to each revision that becomes
ancestor of the current head revision.
- Advantages:
- Mirror (always updated by push from the same source) always have
the same revision numbers.
- The revno assignment list could be reused for refering to state
at particular point in time (in fact, it would be exactly the
same thing as git reflog).
- Bound branches could be forced to have the same revnos.
- Disadvantages:
- More complex to implement.
- More work at runtime and more space needed in a shared
repository, since each branch has it's own mapping.
Both ways, it would be implemented the way revision-history currently
is, just it would list all revisions, not just the path along the
leftmost parent.
Comments?
(Should I put it on the wiki?)
--------------------------------------------------------------------------------
- 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