From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Sat, 21 Aug 2010 12:08:09 +0300 Message-ID: <838w40pc3q.fsf@gnu.org> 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> <4C6F9009.3030105@swipnet.se> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: dough.gmane.org 1282381729 7091 80.91.229.12 (21 Aug 2010 09:08:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Aug 2010 09:08:49 +0000 (UTC) Cc: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org To: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 21 11:08:46 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 1Omk2o-00065g-0C for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 11:08:46 +0200 Original-Received: from localhost ([127.0.0.1]:55593 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Omk2b-0006P5-9m for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 05:07:05 -0400 Original-Received: from [140.186.70.92] (port=38952 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Omk2U-0006NG-2s for emacs-devel@gnu.org; Sat, 21 Aug 2010 05:06:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Omk2R-0005Jc-I8 for emacs-devel@gnu.org; Sat, 21 Aug 2010 05:06:56 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:57510) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Omk2R-0005JQ-9Y for emacs-devel@gnu.org; Sat, 21 Aug 2010 05:06:55 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0L7H00K00VHG9A00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 21 Aug 2010 12:06:07 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.220.100]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7H00KCRVY6AS10@a-mtaout22.012.net.il>; Sat, 21 Aug 2010 12:06:07 +0300 (IDT) In-reply-to: <4C6F9009.3030105@swipnet.se> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) 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:128946 Archived-At: > Date: Sat, 21 Aug 2010 10:36:25 +0200 > From: Jan Dj=E4rv > Cc: emacs-devel@gnu.org >=20 > Uday S Reddy skrev 2010-08-21 00.41: >=20 > > 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 b= ranches, we > > can continue working on the source even when push is running in t= he > > 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. >=20 > You are ignoring the fact that work usually doesn't happen in the b= ound=20 > branch, but in a separate task branch. We can continue to work the= re while=20 > the bound branch commits. Actually, I see no reason not to continue working even in the bound branch that is being committed. There's nothing at all to prevent that, since Bazaar takes note of the files it commits and their contents _before_ it sends changes upstream. That is why you cannot make changes after launching "bzr ci" and hope for them to be include= d in the changeset. (This is unlike CVS, where you could make changes as long as the particular file wasn't sent upstream by "cvs ci".)