[PATCH] bzrk for 0.8 api change

[John A Meinel]

Aaron Bentley wrote:
> Erik Bågfors wrote:
> | Is there no official branch for bzrk that's maintained anymore?
> 
> | I have http://erik.bagfors.nu/bzrk.erik/ that's just the official plus
> | support for branch nicks.
> 
> Oh, cool.  I'll check that one out.
> 
> Aaron

I've been thinking about it. And one thing I would really like to see
about bzrk is to be able to sort the columns, so that specific branches
would be sorted nicely.
For example, being able to say "column 1 => bzr.dev, column 2 =>
integration, column 3 => jam-integration", would make it very nice to
tell who had merged what from whom. Right now the only column that means
anything is the first one (which is *this* branch). Since we are
changing the revision-history practises, we can build up the
revision-history for a number of branches.

I'm not sure how to do it nicely, but it might be as simple as:

1) the leftmost column is the local branch history
2) The first merge gets column 2, and its revision history
   will only be found on either column 1 or column 2
3) continue for all other merges.

The downside of this, is that short-lived branches suddenly take up and
entire column, even though they only have 3 unique revisions.

I suppose we could sort it by the number of unique revisions in a given
branch's history. And then we sort the top ~5 revision-histories, and
the rest use the current allocation scheme.

Another alternative is to just allow the user to specify which histories
get used. (right-click on node, say 'sort history')

I'm not sure what the best scheme is. But right now 'bzr viz' gets
really convoluted, and I think we have the information to make it nice
and sorted. Especially with integration branches, I think we could make
a really nice graph of what is going on. But it needs a little bit more
logic to know what needs to be sorted.

Another possibility would be to just name what branches you want sorted
by there branch nick. But because of the de-coupling, you can have the
same branch-nick in 2 separate revision histories, so this may not work.
Though it may be better to sort by nick, than by revision-history.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060204/65539cd9/attachment.pgp