[MERGE/RFC] Add dotted-decimal revision numbers to merge_sorted output

[John Arbash Meinel]

Daniel Parks wrote:
> On Sep 8, 2006, at 8:15 AM, Matthew D. Fuller wrote:
>> Can we have a little sidetrack on this bit?  I like naming them based
>> on their merge point better than ancestrally, from a tool usability
>> standpoint.
> 
> Delurk! ;)
> 
> This seems like a better solution, to me, too. It's very easy to
> understand, and avoids long strings of numbers (if I understand the idea).

Ancestrally notated numbers are a little bit easier to understand. (This
is the nth commit on a given branch, rather than the 'nth' commit merged
into a given branch).

Using 1969.n.m in *my* head, makes it sound like .n.m comes after 1969
rather than before.

> 
> To use John Arbash Meinel's example from earlier, why can't the revnos
> work like the following (where m and n are numbers):
> 
> ------------------------------------------------------------
> revno: 1969
> committer: Canonical.com Patch Queue Manager<pqm at pqm.ubuntu.com>
> branch nick: +trunk
> timestamp: Tue 2006-08-29 21:29:23 +0100
> message:
>   (spiv) Refactor sftp vendor support
>     ------------------------------------------------------------
>     revno: 1969.n
>     merged: john at arbash-meinel.com-20060829202038-ea1bede06b14bec8
>     committer: John Arbash Meinel <john at arbash-meinel.com>
>     branch nick: jam-integration
>     timestamp: Tue 2006-08-29 15:20:38 -0500
>     message:
>       [merge] Andrew Bennetts: refactor sftp vendor support
>         ------------------------------------------------------------
>         revno: 1969.n.m
>         merged:
> andrew.bennetts at canonical.com-20060829011643-e4e2bd81f615f0df
>         committer: Andrew Bennetts <andrew.bennetts at canonical.com>
>         branch nick: sftp refactoring 2
>         timestamp: Tue 2006-08-29 11:16:43 +1000
>         message:
>           Cosmetic tweaks.
>         ------------------------------------------------------------
>         revno: 1969.n.m-1
>         [ . . . ]
>     ------------------------------------------------------------
>     revno: 1969.n-1
>     [ . . . ]
> 
> The advantage of the ancestor-based revnos would seem to be stability,
> but it seems like the the revid already fills this role. The revno is
> mostly a convenience to avoid having to deal with revids, correct?

Revids are 100% stable across all branches, etc. But they are a real
pain to type. You are pretty much stuck with copy + paste. I don't think
anyone would remember them naturally.

revnos are only stable inside a branch. 2 branches can easily refer to
the same revision by a different revno. (This is very much true already,
though not as obvious because ATM revisions not on the history don't
actually have a revno)

> 
> Maybe I'm completely missing the point. Wouldn't be the first time :).
> 
> Daniel

I actually kind of like merge revnos, because then when looking at
annotations, you can figure out what revision those changes were merged
into the mainline.

I believe merge revnos can be just as stable. Since all you need is a
deterministic numbering scheme, and a deterministic parent ordering. And
we already have the latter.

My big concern with what you proposed, is that it may require multiple
passes through the data. I don't know the intricate details of
merge_sorted, though. It may turn out to be cheaper to do merge revnos.

What might be nice is if we can get Robert to implement both, and then
we can review how they look.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060908/0b97c4c0/attachment.pgp