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 13:41:02 +0300 Message-ID: <834oeop7sx.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> <838w40pc3q.fsf@gnu.org> <4C6FAAD4.7080905@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 1282387155 21594 80.91.229.12 (21 Aug 2010 10:39:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Aug 2010 10:39:15 +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 12:39:12 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 1OmlTk-00075r-6F for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 12:39:12 +0200 Original-Received: from localhost ([127.0.0.1]:55345 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmlTj-00031K-LZ for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 06:39:11 -0400 Original-Received: from [140.186.70.92] (port=55095 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmlTc-000316-Ru for emacs-devel@gnu.org; Sat, 21 Aug 2010 06:39:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmlTb-0000fx-80 for emacs-devel@gnu.org; Sat, 21 Aug 2010 06:39:04 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:43691) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmlTb-0000fl-05 for emacs-devel@gnu.org; Sat, 21 Aug 2010 06:39:03 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L7H00M00ZRK5G00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Sat, 21 Aug 2010 13:39:01 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.220.100]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7I00MAQ08Z2E60@a-mtaout21.012.net.il>; Sat, 21 Aug 2010 13:39:00 +0300 (IDT) In-reply-to: <4C6FAAD4.7080905@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:128952 Archived-At: > Date: Sat, 21 Aug 2010 12:30:44 +0200 > From: Jan Dj=E4rv > CC: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org >=20 > > Actually, I see no reason not to continue working even in the bou= nd > > branch that is being committed. There's nothing at all to preven= t > > that, since Bazaar takes note of the files it commits and their > > contents _before_ it sends changes upstream. That is why you can= not > > make changes after launching "bzr ci" and hope for them to be inc= luded > > in the changeset. (This is unlike CVS, where you could make chan= ges > > as long as the particular file wasn't sent upstream by "cvs ci".) >=20 > This is correct. However any bzr operation like a simple C-x v = =3D fails=20 > because bzr is locked by the commit (it doesn't seem to do read-onl= y locks).=20 > That is the main disadvantage that makes me go back to the task bra= nch. I agree that this is a disadvantage, but is it really that significant? How much do you use bzr operations while developing? Most of development is not about bzr, it's about editing, compiling, and testing. I only need bzr operations when I'm almost done with development, like to see what files are changed or compare them with some other version. No matter how slow is "bzr ci" upstream, the development cycle is much slower, at least for me. It can only be faster if you fix very simple bugs, like typos. YMMV, but this disadvantage doesn't sound a reason good enough to mak= e a cardinal decision to do all the work from a task branch.