[MERGE/RFC] Dotted-decimal revision numbers in 'bzr log'

[Robert Collins]

On Thu, 2006-09-07 at 00:08 -0500, John Arbash Meinel wrote:


> For starters, I'm trying to figure out just how I feel about the new
> dotted forms.
> 
> It is kind of interesting to look back over the ancestry. And it might
> actually give some insights...
> 
> For example, this merge:
> - ------------------------------------------------------------
> 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: 1711.2.133.1.8
>     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: 1951.1.12
>         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.
> 
> spiv had updated some code, and I merged his changes into my integration
> branch, to be ready to merge them into the mainline.
> 
> Now, because we've taken the general stance that integration branches
> are merged from bzr.dev, rather than being pulled (we could do either,
> but it makes it clearer who has done what if you use merge rather than
> pull).
> 
> Anyway, the last time I pulled bzr.dev seems to be revno 1711. And
> someone else branched (or pulled) from that same revision.
> So anyway, 1711.2 seems to be my integration branch.

To get a revno: 1711.2.133.1.8 you need:
three children of 1711 - mainline (1712), one merged branch(1711.1.1),
this branch.
132 commits in this branch.
two children of 1711.2.133 - its mainline (1711.2.134) and this branch.
7 commits in this branch.

Just though I'd point this out - for this to have needed the 2 branch
makers, both branch points must be non-unique (1711 and 1711.2.133). If
the entire branch is merged to the mainline, another commit is done, and
that is then merged to the mainline, the branch numbers are not
destabilised:

Say the branch is 10.1 - you will have 10.1.1, 10.1.2, 10.1.3 once its
merged. But they appear in the branch as '11, 12, 13'. You merge it into
the mainline, which already has an 11. This gives you:
12
  10.1.3
  10.1.2
  10.1.1
11
10
...

If you do another commit to your branch, without pulling or anything,
you get 14. Merging that to the mainline will give you:
13
  10.1.4
12
  10.1.3
  10.1.2
  10.1.1
11
10
...

If you merged the mainline first, your commit would be 15, and the log
in the mainline would look like:
13
  10.1.5
  10.1.4 (this is your merge of mainline)
12
  10.1.3
  10.1.2
  10.1.1
11
10
...


I dont understand what you mean by merging a branch in changing your
integration branches id. I think what happened is that you branched
*from* your integration branch, rather than from bzr.dev, which is
accurately represented in the output.


> So a few interesting things happen.
> 
> 1) You can follow along for quite some time, and see how my integration
> branch evolves, and watch the commits and what branches I spawned from it.
> 
> 2) At 1711.2.133 I branched to create a 'sftp-benchmarks' branch, where
> I created a single patch, which got merged into bzr.dev, before my
> actual jam-integration branch was merged in. So from there, my real
> jam-integration branch becomes 1711.2.133.1.*
> 
> So this is something that we may want to discuss. Because dotted revnos
> actually get really close to giving you a form of branch identity. And
> it is kind of neat. Because of the numbering schemes, you can see that X
> branch was branched off of *this* long-lived branch, rather than *that*
> long lived branch. However, because the numbering is still mostly based
> on when the revisions were merged into the current branch, you get weird
> side-tracks like the one above. And if it happens enough (like if I kept
> branching off of my integration branch, and merging them directly into
> bzr.dev), what would happen? I *think* you would end up with a hugely
> nested mess. Like 1711.2.133.1.8.1.20.1.44.1....
> 
> Where each one of those is a time when a shorter lived branch beat the
> long-lived branch to being merged.

I'd add '*and*' the shorter lived branch came from the long lived one.

> On the other hand, I'm pretty sure I see that Robert has started doing
> more 'bzr pull' to bring his integration branch up to date, rather than
> 'bzr merge'.

Yup, I am - I treat integration as a place to hold pending changes now,
rather than a long lived separate branch.

> Aaron, on the other hand, has been at it even longer than I have, since
> his integration branch is now:
> 1551.2.49.1.40.1.22.1.*

Thats 3 times shorter branches made from his integration branch have
landed, and his branch was second globally created from 1551 to land in
a merge to mainline.

> I'm not sure exactly how he branched and was merged, because they are
> all labeled "Aaron's mergeable stuff".
> 
> But you can see that somehow he did a few commits on his integration
> branch (around ...40.1.22) that resulted in .23,.24,.25
> Which then got merged, and somehow he started over again back at .22 and
> kept going. (My best guess is that he switched machines)
> 
> The same thing happened at 1551.2.49.1.41.
> 
> At least for 1551.2.50,51 he actually had a real win32fixes branch.
> 
> 
> Anyway, to summarize, I think dotted revnos work really well for a star
> pattern. If you look at the more recent commits from me, now that I'm
> using feature branches all over the place. Everything has nice short
> numbers, and it makes it very clear when I branched, how things were
> merged around, etc. And it is kind of nice.
> 
> But for long lived integration branches, the fact that the branch number
> can be supersceded by a short lived quick-fix branch, means that they
> become long-term unstable. If we can find a possible fix for that, I
> think we could have a real winner.
> 
> And I think integration branches will become more common as time goes
> by. Like, think about upstream Debian versus Ubuntu packages, versus the
> Linspire package. When bazaar really takes off (yes, I'm optimistic:),
> you are going to have some long ancestries, and they are going to be
> come as long as the revision ids we are avoiding.

I think branch identity is inherently tricky: the scenarios above where
a 'long lived branch' has its number changed because a peer is merged
before a change to it is a demonstration of the symmetry problem : by
making a system that works any which way, there is no fundamental
difference between the 'new sftp-fixes branch' and the 'original
integration branch'.

Its possible that using branch nicks to refine the assignment process
would work, but I would hesitate to do that for a number of reasons.
Firstly it does not solve the problem when both sides of a split have
the same nickname. Uncommit is an example of how this will occur even
when people are using bzr to make new branches. Secondly, we'd need a
significantly more complex index scheme to get fast performance out of
the generation algorithm for this - we'd need to know all the
descendants of a node, and their order in merge_sort output, before we
could assign any ids. (Because reserving revision.0.1 - the mainline
descendant - for a revision with the same branch nick does not help you
differentiate between two with the same nick, and we would definately
want the one reachable via leftmost-first to be given the blessed spot,
to provide sort stability).

-Rob


-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060907/afb3b8ad/attachment.pgp