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: Sun, 22 Aug 2010 04:52:14 -0400 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> <83aaogpcbu.fsf@gnu.org> <87vd737pxd.fsf@uwakimon.sk.tsukuba.ac.jp> <83pqxboi38.fsf@gnu.org> <87r5hr6qvf.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282467173 6250 80.91.229.12 (22 Aug 2010 08:52:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 Aug 2010 08:52:53 +0000 (UTC) Cc: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 22 10:52:50 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 1On6I8-0001uJ-0R for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 10:52:50 +0200 Original-Received: from localhost ([127.0.0.1]:52738 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On6I0-00050G-B7 for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 04:52:28 -0400 Original-Received: from [199.232.76.173] (port=44771 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On6Hq-0004yk-G9 for emacs-devel@gnu.org; Sun, 22 Aug 2010 04:52:18 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1On6Ho-0004n5-U6 for emacs-devel@gnu.org; Sun, 22 Aug 2010 04:52:18 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:40452) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1On6Ho-0004n0-IS for emacs-devel@gnu.org; Sun, 22 Aug 2010 04:52:16 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1On6Hm-0006Jx-LZ; Sun, 22 Aug 2010 04:52:14 -0400 In-reply-to: <87r5hr6qvf.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) X-detected-operating-system: by monty-python.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:129015 Archived-At: > From: "Stephen J. Turnbull" > Cc: u.s.reddy@cs.bham.ac.uk, > emacs-devel@gnu.org > Date: Sun, 22 Aug 2010 16:36:20 +0900 > > > I could use "ci --local", but that would cause my changes appear on > > a branch when I finally commit upstream, and require the -n0 switch > > to "bzr log", so I try to avoid that. > > isn't a problem if you rebase. Stefan says bzr's rebase is unreliable. I only used rebase in toy use-cases, so I have no first-hand knowledge. Perhaps Stefan could elaborate on the problems he knows about. > > > The recommended workflow (at least as Karl and I wrote it) > > > assumed that "one-commit changes" would be performed in a > > > separate branch, and merged into the mirror (bound branch) in > > > batches. > > > > This would again fly in the face of the "don't lump together..." > > request, AFAIU. > > Then there's something you don't understand. What don't you > understand? I just completely misunderstood the use-case you were describing. Re-reading it now, I don't see any problems of the "lumping" kind, indeed. The only problem is with having the changes on a branch instead of mainline of the history, unless rebase is used. There's one other problem with holding back commits to minor problems: someone else could solve the same problem in the meantime. Apart of the obvious social issues ("I was the first to fix it"), there's the issue of wasted effort. With changes I make for the DOS port, I casually leave them in a local commit for days, because I'm sure no one else will touch them. But with general-purpose changes, we need a mechanism to announce "I'm working on this one", otherwise the urge to commit the results of a job well done is too intense, I think. If all of this were solved, I could probably wait with commits until the end of the day, which will make the commit slowness much less of an issue. I guess no one seriously considered all these issues because we believed (and still do) that bzr will eventually become faster on Savannah. Perhaps one day we will abandon that hope and turn to resolving these issues instead.