Re: Emacs Bazaar repository

[James Westby <jw+debian@jameswestby.net>]

On Sat, 2008-03-15 at 09:39 +0900, Stephen J. Turnbull wrote:
> James Westby writes:
> 
>  > May I point you to my blog post of yesterday that explains some of
>  > these issues, rather than spell if all out here?
>  > 
>  > http://jameswestby.net/weblog/bzr/01-revision-numbers.html
>  > 
>  > The last section is on this particular issue.
>  > 
>  > The gist of it is that topological sorting means that children appear
>  > before their parents. bzr does "merge sorting" that ensures that a
>  > revision does not appear after a revision that it is not an ancestor
>  > of.
> 
> Excuse me?  There may be something sensible you wish to say, but what
> I have quoted is not it.  If A and B are not ordered by ancestry both
> "AB" and "BA" fail to be a "merge sort" according to that criterion.
> 

Sorry, it appears I didn't explain it well enough. I missed the word
"also", as bzr also adds a constraint over and above topo-sorting.
It then also prefers to output left-hand parents first.

Consider the following revision graph (parents above children)

         A
         |\
         B C
         |/
         D

A topo-sort requires that D be emitted before B and C, and that B and C
be emitted before A, but it does not impose an ordering on B and C.

If you add bzr's rules then it prefers to output left-hand parents
first, so it would output B before C. However this would then violate
the other constraint, as C would come after B, but B is not an ancestor
of C. Therefore C must be output before B. Add in the indentation
depending on whether the revision is a left or right hand parent
of the previous revision and you have bzr's log output.

>   The indentation of the merged commits (and the fact they disappear
>   with "--short" and "--line") means that mentally they become of
>   lesser importance.
> 
> But that's exactly what I rarely want.  I know what I did, unless it
> was a long time ago.  What I generally want to know is what others are
> doing, and how that impacts my branch when I merge their code.
> 

Ok, use "bzr merge --pull".

>  > While we may be able to offer some UI improvements to git itself there
>  > may be fundamental differences that mean git may always fall short of
>  > what we would like. There are also things that bzr can do that git
>  > will never do (barring any big changes in direction), for instance
>  > foreign branch support.
> 
> What is "foreign branch support", and why do you think that a program
> which is amounts to being a browser for the universal revision graph
> can't do it?  An URL would do.
> 
> 

I'm sorry, I can't really follow this paragraph. I can explain what we
mean by foreign branch support.

We mean that the bzr client can access the branches/repositories/working
trees of other systems transparently. For instance if you install 
bzr-svn, "bzr branch svn://..." works.

This might not have been the best example, as git-svn exists, and works
great for using git to access svn. However it is not transparent, you
must use the git-svn command for some tasks. Also you can't use the
git client in an svn working tree (checkout) if you have one already.

Thanks,

James