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

Thu Sep 7 06:08:56 BST 2006

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> This adds the dotted decimal revision numbers merge_sorted can create
> into the output of log.
> 
> There are a couple of gotchas, which I will add to NEWS before merging
> [assuming approval ;)] - I forgot to do so when writing the NEWS entry.
> 
> The gotchas are two: Firstly I've deprecated show_merge for
> show_merge_revno in the LogFormatter interface.
> 
> Secondly, I've broken compatability by calling LogFormatter.show() with
> a string revno rather than an int revno. I considered keeping
> compatability here, but there is a fundamental change occuring: revnos
> are no longer representable as ints. We could either use the tuple
> (1,2,3) form, or string "1.2.3" form - for log output I figured an
> opaque to-display form was nicer.
> 
> Sample output for bzr.dev is here:
> http://people.ubuntu.com/~robertc/baz2.0/sample-log.txt
> 
> I think it would be nice to remove the 'merged ...' lines from merged
> revisions, but only once the dotted decimal revision-numbers are
> accessible from commands like 'bzr diff' and 'bzr pull' etc.
> 
> Cheers,
> Rob
> 

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.

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.

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'.

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.*

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.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE/6lnJdeBCYSNAAMRAvs0AJ0Ymf1OfucD9mxxRtcsIhM193drCwCgzW0l
/FWdBOCF37mqKIiGluRAkzc=
=z+1x
-----END PGP SIGNATURE-----