On Mon, 2008-10-13 at 14:15 +0200, Gary van der Merwe wrote: > 2008/10/13 Alexander Belchenko <[EMAIL PROTECTED]>: > > 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
signature.asc
Description: This is a digitally signed message part
-- bzr-gtk mailing list [email protected] Modify settings or unsubscribe at: https://lists.canonical.com/mailman/listinfo/bzr-gtk
