From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Locks on the Bzr repository Date: Sun, 22 Aug 2010 16:36:20 +0900 Message-ID: <87r5hr6qvf.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282462792 27480 80.91.229.12 (22 Aug 2010 07:39:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 22 Aug 2010 07:39:52 +0000 (UTC) Cc: u.s.reddy@cs.bham.ac.uk, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 22 09:39: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 1On59e-0007Xu-HE for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 09:39:47 +0200 Original-Received: from localhost ([127.0.0.1]:40990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On59d-0007qL-O5 for ged-emacs-devel@m.gmane.org; Sun, 22 Aug 2010 03:39:45 -0400 Original-Received: from [140.186.70.92] (port=37414 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1On59W-0007qF-0s for emacs-devel@gnu.org; Sun, 22 Aug 2010 03:39:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1On59T-0000A1-Rv for emacs-devel@gnu.org; Sun, 22 Aug 2010 03:39:37 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:52576) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1On59R-000091-MZ; Sun, 22 Aug 2010 03:39:34 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp (imss12.cc.tsukuba.ac.jp [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 43752F4003; Sun, 22 Aug 2010 16:39:30 +0900 (JST) Original-Received: from mgmt2.sk.tsukuba.ac.jp (unknown [130.158.97.224]) by imss12.cc.tsukuba.ac.jp (Postfix) with ESMTP id 32F4BF4002; Sun, 22 Aug 2010 16:39:30 +0900 (JST) Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2DFC7970303; Sun, 22 Aug 2010 16:39:30 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 704E81A2C38; Sun, 22 Aug 2010 16:36:20 +0900 (JST) In-Reply-To: <83pqxboi38.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:129007 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > > Cc: Uday S Reddy , > > emacs-devel@gnu.org > > Date: Sun, 22 Aug 2010 03:59:10 +0900 > > > > > For the first kind, it is IMO not very good to have the > > > changes uncommitted upstream for prolonged periods of time, > > > > What's your definition of "prolonged"? > > Never thought about quantifying that. It seems like a moot point > anyway, since there's a request not to lump unrelated changes in > the same commit. It's not a moot point because > 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. There's a small race (about 10 minutes for me on XEmacs with a make; make check[1]) where somebody might commit while you're rebasing, which would cause push/bound-commit to fail, but you get a fast-forward (commits all on mainline) when the push succeeds. And it will usually succeed. > > I'm thinking in terms of simply committing all changes locally > > until the end of the work session, then doing the merge to mirror > > and push to upstream in a batch at the end of the session. > > That'd be against the "not lumping together unrelated changes" > request. Why do you think that? Separate commits are separate commits. They are recorded as separate commits in upstream when you push. > > How frequently do you commit? > > Very frequently, see above. Heh. Given that for you each commit goes upstream, that's frequent. But with git I've used workflows that substitute commits for autosaves. That's what I think of as "very frequent". > > How finely do you divide changesets? > > Each changeset deals with a separate feature or bug-fix. That is > how I understand the rules. That's what I thought, and > > I will often make 5 to 10 commits in a session when I'm working > > on minor bugs. > > Same here, although it's more close to 5 than to 10. so your workflow in this respect is roughly similar to my own (ie, the rate of mainline commits is the same, although I tend to break up anything that involves more than five minutes work into multiple commits on a branch, in both git and hg). Ten is unusual for me, but not so unusual (especially when I'm wearing my RM hat) that I can afford to ignore the possibility that I'll want to do ten commits and end up spending 30 minutes minimum waiting for the server. That's like 20% of my typical session, and if any of those commits really hangs I could end up wasting half the session. > > I really would not like it if I had to wait even one minute for a > > commit of a typo fix. > Well, you cannot make a changeset of a typo fix with anything else, > unless it's another typo. The problem is that one rarely finds > many typos in one go, except by luck. So yes, I need to wait > before the next commit. I do other things, like reading mail or > work on some other problem in the meantime. Right. Context switches are expensive. I'd rather avoid them, myself. YMMV. The "commit+ pull rebase push" workflow means that all of my waiting is concentrated on the last three operations, and my train of thought is never interrupted (because that part of the workflow is a no-brainer). > > No, but if you do a typo fix, commit, then find another typo, 50 > > minutes (according to the recent report) is a very long time to > > wait.... > Well, 50 minutes _is_ long. It's more like 3 to 5 here, which is > also long, but barely endurable. You have more endurance than I. I am not willing to put up with that. > > 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? That this workflow involves committing each of several conceptual changes separately, then one push (or merge + commit in a bound branch) to send them all upstream? Or that each commit is a separate transaction, cherrypickable and logged as such, even after a pull/push/bound-commit to a different repo? Or something else? Footnotes: [1] Not doing the equivalent of "make bootstrap" is a little risky because we don't have proper dependencies for Lisp ... this matters mostly for changes to exported APIs not exercised by the build and test process, or to exported macro internals, both of which are pretty rare. I consider the level of risk acceptable.