From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: James Westby Newsgroups: gmane.comp.version-control.bazaar-ng.general,gmane.emacs.devel Subject: Re: Emacs Bazaar repository Date: Sat, 15 Mar 2008 10:30:21 +0000 Message-ID: <1205577021.6161.462.camel@flash> References: <87skyvse7k.fsf@xmission.com> <86ejae96t4.fsf@lola.quinscape.zz> <47DA3601.3040507@arbash-meinel.com> <85d4px4edd.fsf@lola.goethe.zz> <1205502278.6161.398.camel@flash> <857ig54dak.fsf@lola.goethe.zz> <1205503781.6161.405.camel@flash> <87od9gstuv.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1205576951 27374 80.91.229.12 (15 Mar 2008 10:29:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 15 Mar 2008 10:29:11 +0000 (UTC) Cc: bazaar@lists.canonical.com, David Kastrup , Matthieu Moy , schwab@suse.de, emacs-devel@gnu.org, Eli Zaretskii To: "Stephen J. Turnbull" Original-X-From: bazaar-bounces@lists.canonical.com Sat Mar 15 11:29:39 2008 Return-path: Envelope-to: gcvbg-bazaar-ng@m.gmane.org Original-Received: from chlorine.canonical.com ([91.189.94.204]) by lo.gmane.org with esmtp (Exim 4.50) id 1JaTdv-0005Le-Jj for gcvbg-bazaar-ng@m.gmane.org; Sat, 15 Mar 2008 11:29:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1JaTdM-0003uP-HN; Sat, 15 Mar 2008 10:29:00 +0000 Original-Received: from jameswestby.net ([89.145.97.141]) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1JaTdJ-0003uA-Pz for bazaar@lists.canonical.com; Sat, 15 Mar 2008 10:28:57 +0000 Original-Received: from 77-99-12-164.cable.ubr13.azte.blueyonder.co.uk ([77.99.12.164] helo=[192.168.1.109]) by jameswestby.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JaTdH-0003Bs-BH; Sat, 15 Mar 2008 10:28:55 +0000 In-Reply-To: <87od9gstuv.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Evolution 2.22.0 X-BeenThere: bazaar@lists.canonical.com X-Mailman-Version: 2.1.8 Precedence: list List-Id: bazaar discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bazaar-bounces@lists.canonical.com Errors-To: bazaar-bounces@lists.canonical.com Xref: news.gmane.org gmane.comp.version-control.bazaar-ng.general:38637 gmane.emacs.devel:92667 Archived-At: 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