A not so idle thought

[Russel Winder]

On Mon, 2008-10-13 at 14:15 +0200, Gary van der Merwe wrote:
> 2008/10/13 Alexander Belchenko <bialix at ukr.net>:
> > Russel Winder пишет:
> >>
> >> In a shared repository though we have the same model as Mercurial and
> >> Git, lots of local branches in a single repository.  Have I just missed
> >> the gitk-like tool of Bazaar for managing these branches?  If I haven't
> >> I wonder if putting it on the road map a good move?  Should Olive-GTK be
> >> able to handle multiple branches at once? (At least in a shared
> >> repository.)
> >
> > QBzr's qlog already able to show you log of all branches inside shared repo
> > (thanks to Gary van der Merwe who implement this). This is makes `bzr heads`
> > less useful for me now.
> >
> > I have no idea does bzr-gtk's viz has this feature or not.
> 
> bzr-gtk's viz allows you to specify a number of branches. It would be
> trivial to make it find all the branches in a shared repo.

OK I tried this and it does show both branches and colours the graphics
appropriately, but it doesn't show the branch nick graphically other
than this.  Having a marker for the tip of each branch is the crucial
information that qlog and gitk are showing.

Can I propose that if bzr is initiated in a shared repository then it
does show all the branches (on the assumption they are related).  If it
is straightforward then it shouldn't be a hassle.

Why viz and not glog as the name of the command?

> One of the limitations of both qlog and viz, is that it tires to load
> the revisions from the first branch specified. With viz, if you
> specify two stand alone branches (not in a shared repo) and the second
> branches has a revision that is not in the first one's repo, then it
> will silently fail to show that revision. With qlog, we require that
> the branches share a repo.

I appreciate that there are serious problem is the branches in a shared
repo are not actually related, but is there a half way house of doing
the gitk thing as much as possible?

> To overcome this limitation, we will need to store, for each rev,
> which branch/repo it can be retrieved from. We will need to
> reimplement a number for Graph functions, starting with iter_ancestry,
> to accommodated this.
-- 
Russel.
====================================================
Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081014/316cdf7d/attachment.pgp