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 18:48:31 +0300 Message-ID: <83wrrknf00.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> <83aaogpcbu.fsf@gnu.org> <19567.50977.609000.549262@gargle.gargle.HOWL> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282405610 10809 80.91.229.12 (21 Aug 2010 15:46:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Aug 2010 15:46:50 +0000 (UTC) Cc: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 21 17:46:49 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 1OmqHQ-0001I5-CY for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 17:46:48 +0200 Original-Received: from localhost ([127.0.0.1]:54026 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmqHP-00074l-Or for ged-emacs-devel@m.gmane.org; Sat, 21 Aug 2010 11:46:47 -0400 Original-Received: from [140.186.70.92] (port=48666 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmqHD-00070K-Cu for emacs-devel@gnu.org; Sat, 21 Aug 2010 11:46:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmqH9-0005eG-4v for emacs-devel@gnu.org; Sat, 21 Aug 2010 11:46:35 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45522) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmqH8-0005dl-SL for emacs-devel@gnu.org; Sat, 21 Aug 2010 11:46:31 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L7I00C00EH2KR00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 21 Aug 2010 18:46:29 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.220.100]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7I00BWVEHFHXH0@a-mtaout20.012.net.il>; Sat, 21 Aug 2010 18:46:29 +0300 (IDT) In-reply-to: <19567.50977.609000.549262@gargle.gargle.HOWL> 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:128973 Archived-At: > Date: Sat, 21 Aug 2010 13:31:29 +0100 > From: Uday S Reddy > Cc: Uday S Reddy , > emacs-devel@gnu.org > > Commiting/sychronizing "frequently" is still better than commiting > instantly. It gives you a choice as to how frequently you > synchronize. That might depend on the urgency of the fixes and server > contention levels. Bound branches remove that choice. Strictly speaking, they don't. There's still "ci --local". Anyway, I don't care much about this choice, because I always choose to sync and commit. I already explained the reasons. > As for interspersing bug-fixes and new features, I would pick and > choose depending on the situation. A half-finished new feature > sitting in the trunk doesn't hurt anybody. I might leave it in. Really?? I doubt many developers will do the same. I certainly won't, not as long as the development code is used by many people. > (People are expected to use the new feature only after it gets into > the NEWS file.) I actually read the ChangeLog files each time I resync. I won't be surprised if many others did the same to learn about news. There's also the emacs-diffs mailing list which is great for watching new developments; all commits go there, so NEWS don't count. > Or, if I don't feel comfortable about it, I would > probably push my current main branch as a task branch, reset the main > branch to the old state (using uncommit), and attend to the urgent bug > fix in the main branch. Or, I might do the urgent bug fix in a new > mirror of the central repo and push it. It will then reappear as part > of rebase in my main branch. So, there are lots of ways of doing it. Yes; and all of them are quite complicated and more error-prone than the simple ones. To me that means they should be used only when necessary (which I do), not as a matter of routine. > 1. Allows you to synchronize with central repo less frequently. > > 2. Allows you to choose when to synchronize. These two are the same. > 3. Keeps your related commits to the mainline together. This one is unrelated to boundness of the branch. I can do the same in a bound branch -- I just need to wait with committing until all the "related" changes are ready to go. > 4. Allows you to go from bug-fixing mode to (small) development mode > and back, without much pain. Not without some pain. > 5. Allows you to choose between many different workflows, and even to > switch from one to the other on the fly, whereas bound branches seem > to allow only one workflow. Since I have local unbound branches anyway, this is not an advantage at all. Whenever I need this, I simply switch to one of the local branches. There are bzr tricks to move all your uncommitted changes to a different branch, and I use them in that case. > Having always used unbounded branches, I came into this discussion > wanting to learn why bound branches are being used by you guys. I > still don't know why. But I can see that it makes you feel a lot more > comfortable. As I wrote elsewhere, the only real advantage is the simplicity of the workflow. To me, that is important, as is the fact that simplicity makes my work less error-prone. With the little time I have, any errors on my side could take days to be fixed, and I don't like to cause long-term breakage. YMMV.