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: Fri, 20 Aug 2010 18:19:53 +0300 Message-ID: <83lj81pazq.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282317623 15992 80.91.229.12 (20 Aug 2010 15:20:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2010 15:20:23 +0000 (UTC) Cc: jan.h.d@swipnet.se, schwab@linux-m68k.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 20 17:20:18 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 1OmTOB-0004pq-Eo for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 17:20:16 +0200 Original-Received: from localhost ([127.0.0.1]:51934 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmTOA-0001gY-Ey for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 11:20:14 -0400 Original-Received: from [140.186.70.92] (port=59864 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmTNy-0001f3-R6 for emacs-devel@gnu.org; Fri, 20 Aug 2010 11:20:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmTNW-0002Ih-Pt for emacs-devel@gnu.org; Fri, 20 Aug 2010 11:20:02 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:49868) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmTNW-0002IQ-D6 for emacs-devel@gnu.org; Fri, 20 Aug 2010 11:19:34 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0L7G00H00IILUH00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 20 Aug 2010 18:19:33 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.220.100]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7G00HQFIKILB80@a-mtaout21.012.net.il>; Fri, 20 Aug 2010 18:19:33 +0300 (IDT) In-reply-to: <871v9t8klf.fsf@uwakimon.sk.tsukuba.ac.jp> 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:128927 Archived-At: > From: "Stephen J. Turnbull" > Cc: jan.h.d@swipnet.se, > schwab@linux-m68k.org, > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Fri, 20 Aug 2010 22:44:28 +0900 > > 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. Please show this workflow in more detail. Without the details, it's hard to tell what you suggest. You could be thinking about things possible with git, but not with bzr; it happened in the past. And please drop the ad hominem, you are (again) incorrectly assuming that I don't use distributed workflows. You can see that this is not so if you look at my commits in "bzr log" . > 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. I do want and do use some of them. Please don't mistake a critical opinion for rejection. Instead, back up your opinions by valid arguments, and maybe I will be able to actually learn something from you. > 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). I don't use lightweight checkouts. I use one bound branch and 2 or 3 local branches. I have no problems with local commits, which I use a lot. The problem happens when I need to commit to the master repository. I need to do that from time to time, because my local commits are not available to others, so if I fix bugs, my fixes will not be good to anyone until I commit to upstream. And doing so is painfully slow, and there seems to be no way around it. On top of that, sometimes a commit fails, because someone holds a lock or because some other commit was "sneaked" in in the meantime. So I need to watch the commit and make sure it succeeds, or start another one if it doesn't. So please don't tell me this is asynchronous, because it isn't, at least not entirely. > > 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. How do you know? How frequently do you commit to the Emacs repo? > > > 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. You are talking from the POV of someone who has a lot of time on his hands, or has a fast enough connection to make the delay insignificant. By contrast, I have maybe a few hours during a weekend to work on Emacs, with maybe half an hour on weekdays. Every delay counts, and there's no "at my convenience". > *You* need to defend your deprecation of "push." I don't deprecate "push", so I have nothing to defend. > All workflows have disadvantages. Big deal. No big deal. But the disadvantages of each workflow need to be well understood before making a decision which one to use. And the considerations might well be different given one's personal circumstances and connectivity. Careful examination of the advantages and disadvantages does not constitute deprecation, and should not be treated with derogation. > That's not a reason for a general deprecation of "bzr push". I don't deprecate "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. As long as you commit to the master repo, you will become blocked sometimes. And if you think that my development is blocked while the commit grinds away, then you are simply wrong, because I have additional branches where I can and do develop in the meantime. But the slow commits that sometimes fail after many seconds if not minutes are an annoyance anyhow, and no amount of preaching the "push" ways can do anything about it. > 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 Exactly. And as I explained in another mail in this thread, this calls for testing after I merge, which is one factor why the chances are high to have some other commit sneaked in before I commit. > and what you're doing is short-circuiting that process. What am I doing that short-circuits this 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. Don't ass-u-me that I'm committing without testing after the merge. > I don't expect this to change your mind about *your* workflows. Looks like you have no idea at all what _is_ my mindset regarding the possible workflows. Perhaps you think you are talking to someone else. > 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. I don't deprecate "push.