From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: VC and bzr. Date: Thu, 22 Apr 2010 21:31:44 +0200 Message-ID: <87sk6n4733.fsf@telefonica.net> References: <4BCF45FA.1060808@swipnet.se> <4BCFDE02.5090808@swipnet.se> <4BD01AC9.1000200@swipnet.se> <4BD0395F.7040500@swipnet.se> <87eii7629z.fsf@telefonica.net> <87aasv5zsz.fsf@telefonica.net> <87633j5ya8.fsf@telefonica.net> <871ve75t1e.fsf@telefonica.net> <83633j48mi.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271965170 32251 80.91.229.12 (22 Apr 2010 19:39:30 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Apr 2010 19:39:30 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 22 21:39:28 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O52F0-0003uw-6K for ged-emacs-devel@m.gmane.org; Thu, 22 Apr 2010 21:39:28 +0200 Original-Received: from localhost ([127.0.0.1]:37407 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O52Ex-0003UX-7W for ged-emacs-devel@m.gmane.org; Thu, 22 Apr 2010 15:39:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5286-00082s-Oo for emacs-devel@gnu.org; Thu, 22 Apr 2010 15:32:06 -0400 Original-Received: from [140.186.70.92] (port=39581 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5285-000810-9E for emacs-devel@gnu.org; Thu, 22 Apr 2010 15:32:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5282-0006tS-HV for emacs-devel@gnu.org; Thu, 22 Apr 2010 15:32:04 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:34524) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5282-0006rn-4s for emacs-devel@gnu.org; Thu, 22 Apr 2010 15:32:02 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O527y-00007q-2g for emacs-devel@gnu.org; Thu, 22 Apr 2010 21:31:58 +0200 Original-Received: from 83.42.12.8 ([83.42.12.8]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2010 21:31:58 +0200 Original-Received: from ofv by 83.42.12.8 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 22 Apr 2010 21:31:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 38 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.12.8 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:WNZ4TQIIQbtMieFxDAntpLmVRAs= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:124075 Archived-At: Eli Zaretskii writes: >> Both `bzr log' and `git log --first-parent' are screwed by the workflow >> >> merge from trunk into my feature branch >> then, push to trunk > > Unless you work on a feature for a very long time (months), there > should be no reasons for the "merge from trunk" part. Merging from trunk into a feature branch is not a serious problem (it creates some noise on the history with the associated slowdown on bzr's responsiveness, but that's all). But pushing to trunk after merging is a serious problem as you (Eli) discovered: http://thread.gmane.org/gmane.emacs.devel/120336/ See the output of bzr log -r 99379 -n0 and notice how revisions that once resided on the leftmost part of the DAG now appear on `trunk' as if they were merged by revision 99379. [snip] > Perhaps we should modify the instructions on the wiki slightly, to > make the workflow slightly less annoying due to frequent slow commits > and at the same time avoid screwing up what "bzr log" shows on the > mainline. The last part is fixed: the Emacs repo will reject operations that lead to "bzr log" breakage. The solution for the annoying slowness of commit operations is the smart server, and if that doesn't reduce the required time to something reasonable, the Bazaar people have the means for fixing the problem.