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: Fri, 20 Aug 2010 22:44:28 +0900 Message-ID: <871v9t8klf.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1282312063 24786 80.91.229.12 (20 Aug 2010 13:47:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2010 13:47:43 +0000 (UTC) Cc: jan.h.d@swipnet.se, schwab@linux-m68k.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 20 15:47:41 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 1OmRwa-0006qK-GB for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 15:47:41 +0200 Original-Received: from localhost ([127.0.0.1]:40542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmRwZ-0004hx-R1 for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 09:47:39 -0400 Original-Received: from [140.186.70.92] (port=45624 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmRwQ-0004gv-QE for emacs-devel@gnu.org; Fri, 20 Aug 2010 09:47:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmRwP-0004ad-Jd for emacs-devel@gnu.org; Fri, 20 Aug 2010 09:47:30 -0400 Original-Received: from imss12.cc.tsukuba.ac.jp ([130.158.254.161]:53254) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmRwN-0004ZR-UV; Fri, 20 Aug 2010 09:47:28 -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 CA120F4003; Fri, 20 Aug 2010 22:47:23 +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 BB6E9F4002; Fri, 20 Aug 2010 22:47:23 +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 B70359702E1; Fri, 20 Aug 2010 22:47:23 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 7569F1A2C38; Fri, 20 Aug 2010 22:44:28 +0900 (JST) In-Reply-To: <83tymppj62.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:128923 Archived-At: Eli Zaretskii writes: > If I ever only "bzr merge" from the remote repository, won't my > pushes to it cause my local commits appear on a branch, and the > point of push appear as a merge to mainline? If so, that's what I > meant. Sure. So don't do that. One (probably for values of "one" != "eliz") can pull instead, and rebase when necessary to get that to succeed. Or one can use a separate branch for each task. There are lots of strategies; you don't have to use them if you don't want to. But some people would rather spend 5 minutes fiddling with a rebase once a week (which can be done at your convenience) or so than ever spend 50 minutes waiting for a commit to finish (which blocks you from doing any other commit, if you depend on lightweight checkouts from upstream). > With the rate of commits to the Emacs repository, the chances that > someone "sneaks in a commit before you start your push" are 100%. That's an exaggeration. It might be quite high, but if it's really that high that pushes never succeed, any integration where developers decided asynchronously when to commit to the public repo (including both push and commits in bound branches) is going to run into problems. > We have committers in all time zones, so there's no time that you > are safe. That depends on one's definition of safe. My definition of safe is "my commit is safely in a repository with a known relationship to the upstream", I can commit any time the fit takes me, and I can push when I feel like dealing with the costs of cooperation like merge conflicts. > > but I would imagine you normally need less locking and a lot less > > time if the push succeeds. > This needs testing and measuring; I won't believe it until I > actually see it. The time to push is still governed by network > traffic, which takes most of the time, about 90%, of a commit as > well. Not if you count *time developer is blocked* instead of *time from start of operation to end of operation*. Push is asynchronous; with a DVCS you don't even need to care if it succeeds, you just work on another branch. If it succeeded, you're done. If not, you make adjustments and try again later, at your convenience. (What those adjustments are depends on the exact workflow.) > And even if it is true that this is faster, what you describe hints > on a much more complex workflow that needs a much more diligent > user who knows much more about bzr than most contributors. Sure. So what? I don't need to defend a deprecation of "checkout --lightweight". I don't like it, but I haven't ever suggested that it be forbidden. *You* need to defend your deprecation of "push." > Any blunder there, and you need to work much harder and at least > partially by hand to restore the situation where your branch is "a > superset of the remote repo's history". So this workflow still has > disadvantages, All workflows have disadvantages. Big deal. That's not a reason for a general deprecation of "bzr push". > > It's true that if you only ever use bound branches, all your > > commits must end up on the mainline, and that may be the best > > strategy for some people. But other people like to commit more > > frequently and/or offline. > Me too, but having a separate local branch and merging locally with > a bound branch has all the advantages of the frequent fast commits, > and only one disadvantage -- the commits appear on a branch (unless > I rebase). No, it has another disadvantage, which is that you can hang up on concurrent commits by other developers, just as with the push strategy. Perhaps it's a little less apparent work because you're only blocked on merges with conflicts, but once again you're blocked until your commit succeeds. It's also somewhat dangerous to just merge everything; a diligent developer should treat a merge in such case as "my commit needs review in the new context before committing", really, and what you're doing is short-circuiting that process. (Linus famously flamed Dave Miller for this.) Any merge (which includes rebasing, which is what davem was doing) implies your code is now untested until you rerun the tests. So if you merge into a bound branch, you're automating commits of untested code to the public repo. That may be OK with you (after all, the test results are only a little bit stale, they're probably not growing mold and mushrooms yet), but that is what you're doing. I don't expect this to change your mind about *your* workflows. But there are good arguments for other workflows, there are definite weaknesses in the ones you like as well, and I don't think it's a good idea to deprecate push-based workflows for those who want to use them.