From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.comp.version-control.bazaar-ng.general,gmane.emacs.devel Subject: Re: Emacs repository benchmark: bzr and git Date: Fri, 28 Mar 2008 21:17:37 -0400 Message-ID: References: <20080318154316.GA6242@mithlond.arda.local> <47DFE4EA.5000600@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1206753494 8621 80.91.229.12 (29 Mar 2008 01:18:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Mar 2008 01:18:14 +0000 (UTC) Cc: bazaar@lists.canonical.com, rms@gnu.org, lennart.borgman@gmail.com, emacs-devel@gnu.org, tlikonen@iki.fi To: Vincent Ladeuil Original-X-From: bazaar-bounces@lists.canonical.com Sat Mar 29 02:18:44 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 1JfPiW-0002qU-JM for gcvbg-bazaar-ng@m.gmane.org; Sat, 29 Mar 2008 02:18:44 +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 1JfPhq-00025W-Kq; Sat, 29 Mar 2008 01:18:02 +0000 Original-Received: from 206-248-178-205.dsl.teksavvy.com ([206.248.178.205] helo=ceviche.home) by chlorine.canonical.com with esmtp (Exim 4.60) (envelope-from ) id 1JfPhn-00024v-H4 for bazaar@lists.canonical.com; Sat, 29 Mar 2008 01:17:59 +0000 Original-Received: by ceviche.home (Postfix, from userid 20848) id CADF9B40B7; Fri, 28 Mar 2008 21:17:37 -0400 (EDT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) 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:39478 gmane.emacs.devel:93732 Archived-At: Stefan> Actually, this last point is the same as the second. As for the Stefan> remaining three they come in this order: Stefan> * bzr st needs to be instantaneous. Stefan> * bzr diff -r needs to take at most a couple of seconds Stefan> * bzr log needs to be much faster for single files[1] and for Stefan> subsets of history. Stefan> The first is very serious since it make vc-bzr Stefan> unusable. Actually, I've just installed a patch in Emacs's trunk to make vc-bzr.el parse the dirstate file more completely, so `bzr status' is not needed nearly as often. But I don't have any documentation about the dirstate format, so it's not very satisfactory. Anybody knows where I can find some doc about that file's format? > Can you tell us which precise information is needed by vc-bzr (my > understanding, dating from vc-cvs years ago now, is that it wants > to display the file version in the mode line). It wants to know if the file is under Bzr's control, whether it's added/removed/edited/uptodate and what is the current revision number (basically). Ideally also if there are conflicts (tho it currently doesn't use `bzr status' for that but just looks for the .MINE and friends instead). > I suspect that 'bzr st' aim does not fit vc-bzr needs at all > (even if it's the closest available command from bzr). It seems to fit just fine, except it takes an insance amount of time to give me the list of pending merges. 2 problems with that: 1 - performance 2 - the list includes merges that are not pertinent (because that merge does not affect the specified file(s)). Admittedly, the worst part Stefan> Also, given the current performance problems, we Stefan> haven't tried much more. E.g. I have no idea how Stefan> easy it will be to keep Bzr-Emacs in sync with Gnus's Stefan> repository. > Does that mean that Gnus is maintained as a separate project and > regularly kept in sync/imported in the emacs CVS repository ? Yes, the two branches are sync'd both ways (I believe they both currently use CVS as the main repository and the sync'ing is done semi-automatically via Arch). > If yes, the best solution will be what bzr call 'nested trees' > which is currently working on. I'm not sure this will be sufficient: the Gnus files are not all neatly confined within a single directory. Arch handles such cases just fine (patches to Emacs files that aren't in Gnus are just ignored and the rename support is sufficiently good to be able to figure out which files correspond to which between the two projects; better yet, the two projects were brought together after the fact and the renames are properly handled even without a common ancestor thanks to the use of arch-tags in the files). > I think you both agree :) Internally bzr tends (this is less and > less true) to process the whole tree and then filter the results. Could be. I hope not: the lessons learned from Arch should include avoiding to touch/construct/look-at files unless absolutely necessary. But I'm sure it's not the only problem: the speed difference between "bzr tags" and "bzr tags --show-ids" can't be due to whole-tree operations. Stefan