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: Locks on the Bzr repository Date: Fri, 20 Aug 2010 14:52:24 +0200 Message-ID: <878w418n07.fsf@telefonica.net> References: <4C6D56DB.7040703@swipnet.se> <4C6D8EC5.7040901@swipnet.se> <4C6E1F0A.7070506@swipnet.se> <837hjlr78p.fsf@gnu.org> <87zkwhtws5.fsf@uwakimon.sk.tsukuba.ac.jp> <83tymppj62.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 1282308767 10715 80.91.229.12 (20 Aug 2010 12:52:47 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2010 12:52:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 20 14:52:47 2010 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 1OmR5R-0007gy-Be for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 14:52:45 +0200 Original-Received: from localhost ([127.0.0.1]:53765 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmR5Q-000869-LR for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 08:52:44 -0400 Original-Received: from [140.186.70.92] (port=42300 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmR5K-00084e-FQ for emacs-devel@gnu.org; Fri, 20 Aug 2010 08:52:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmR5J-0004Bx-2h for emacs-devel@gnu.org; Fri, 20 Aug 2010 08:52:38 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52708) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmR5I-0004Be-NW for emacs-devel@gnu.org; Fri, 20 Aug 2010 08:52:37 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OmR5G-0007Zk-6p for emacs-devel@gnu.org; Fri, 20 Aug 2010 14:52:34 +0200 Original-Received: from 83.42.13.171 ([83.42.13.171]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2010 14:52:34 +0200 Original-Received: from ofv by 83.42.13.171 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Aug 2010 14:52:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 36 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 83.42.13.171 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:NbHuKQYv8mqwRXQbhgxJkuKlDaY= 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:128918 Archived-At: Eli Zaretskii writes: [snip] > Me too, but having a separate local branch and merging locally with a > bound branch has all the advantages of the frequent fast commits, and > only one disadvantage -- the commits appear on a branch (unless I > rebase). The workflow is much simpler, though. That's why this is > what I do when I work on something that is not a 5-min job. Just to clarify: merge+push has the side effect of twisting the DAG. This means that the left arm becomes the right, and the right the left. As Eli says, you'll need to use `bzr log -n0' for seeing the commits that previously were visible with `bzr log' (sans the -n0) In general, the DAG becomes a mess. But, worse of all, revision numbers change, because revision numbering depends on how far from the left is the branch of the DAG that contains the commit. What now is revision 1000 after a merge+push can be revision 995.3.2, and some time later 998.5.3.2. This would force us to use the awkward bzr revision ids for referring revisions. The Right Thing if you want to accumulate several unrelated local changes and send them upstream on one batch is to rebase+commit, which appends your commits to the tip of upstream's branch. This is not very different from Git. On Git it is not so bad to merge+push for incoporating your feature branch into mainline (it twists the DAG sides too, but Git does not make big differences among them.) However, for sending a series of unrelated commits, the Right Thing on Git is to rebase+push, which is mostly equivalent to bzr's rebase+commit. All this was previously discussed on the list. And we had already some instances of revision renumbering, so the configuration of upstream repo was changed for rejecting the operations that would twist the DAG.