From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Fri, 20 Aug 2010 23:41:13 +0100 Message-ID: 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> <871v9t8klf.fsf@uwakimon.sk.tsukuba.ac.jp> <83lj81pazq.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1282344116 16614 80.91.229.12 (20 Aug 2010 22:41:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2010 22:41:56 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 21 00:41:55 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 1OmaHa-0007iZ-In for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 00:41:55 +0200 Original-Received: from localhost ([127.0.0.1]:41135 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmaHZ-0005ic-Hw for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 18:41:53 -0400 Original-Received: from [140.186.70.92] (port=44490 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmaHS-0005hx-73 for emacs-devel@gnu.org; Fri, 20 Aug 2010 18:41:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmaHQ-00036m-Uy for emacs-devel@gnu.org; Fri, 20 Aug 2010 18:41:46 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:45754) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmaHQ-00036V-L1 for emacs-devel@gnu.org; Fri, 20 Aug 2010 18:41:44 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1OmaHO-0007g1-C3 for emacs-devel@gnu.org; Sat, 21 Aug 2010 00:41:42 +0200 Original-Received: from cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com ([92.232.137.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Aug 2010 00:41:42 +0200 Original-Received: from u.s.reddy by cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 21 Aug 2010 00:41:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 82 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: cpc10-harb6-0-0-cust112.perr.cable.virginmedia.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 In-Reply-To: <83lj81pazq.fsf@gnu.org> 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:128937 Archived-At: Perhaps I can sneak in a few comments while Stephen is offline. I have found this debate quite enlightening and it helped me understand the limits of "distributed" VCS. (I use unbound local branches in working on VM and always wondered why you guys use bound branches. I am beginning to understand a little bit now.) On 8/20/2010 4:19 PM, Eli Zaretskii wrote: >> >> Sure. So don't do that. One (probably for values of "one" != "eliz") >> can pull instead, and rebase when necessary to get that to succeed. > > Please show this workflow in more detail. Without the details, it's > hard to tell what you suggest. You could be thinking about things > possible with git, but not with bzr; it happened in the past. I think one needs to do a pull before each commit, to be safe. (Seems to be the same as update-commit cycle for bound branches.) If you have already done a series of commits and lost the opportunity to pull, then you have to rebase. If even that seems too far out, then you have to make your changes into a separate branch and merge it in later. > I don't use lightweight checkouts. I use one bound branch and 2 or 3 > local branches. I have no problems with local commits, which I use a > lot. The problem happens when I need to commit to the master > repository. I need to do that from time to time, because my local > commits are not available to others, so if I fix bugs, my fixes will > not be good to anyone until I commit to upstream. It seems to me that committing to the bound branch is essentially like push. (Somebody said you were "discouraging" push. I don't see it. Your every commit is a push.) However, we get to use our local mirror of the trunk as if it were a local branch. We can commit to it without affecting anybody else and do a public commit only in the end. We can commit to it as often as we please, keep a careful log, do enough testing etc. And, this local branch can magically turn back into a proper mirror as soon as we do a rebase-push. You can't get this with bound branches. Your local branches have to be necessarily separate branches, whose histories will appear as merges in the mainline. We use separate local branches as well, when they are appropriate. But we are not forced to use them all the time. (Generally, I am happy to use the main branch for a few days worth of work where I can see the end clearly. I use separate branches for things that might take a few weeks, or things of a more open-ended nature.) And doing so is > painfully slow, and there seems to be no way around it. On top of > that, sometimes a commit fails, because someone holds a lock or > because some other commit was "sneaked" in in the meantime. So I need > to watch the commit and make sure it succeeds, or start another one if > it doesn't. So please don't tell me this is asynchronous, because it > isn't, at least not entirely. Seems to me that you are reinforcing Stephen's point. With bound branches, your branch is locked up until the commit goes through. You can't do anything while you have uncommitted changes in your source. With unbound branches, we can continue working on the source even when push is running in the background, because the source tree doesn't have any uncommitted changes. We can also give up on the push if necessary and continue committing to the branch. The advantage seems quite clear to me. > No big deal. But the disadvantages of each workflow need to be well > understood before making a decision which one to use. I can't believe that you guys really understood the disadvantages of your current workflow before settling on it. The most illuminating revelation I found in Stephen's post is that, with bound branches, every commit is a merge. Most of the time, it is untested and unsafe. This is the biggest disadvantage of all, if you ask me. It also occurs to me that, by asking everybody to use bound branches, you have massively increased the contention on your public repo and the server. That is making your problems worse. Cheers, Uday