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 15:23:17 +0300 Message-ID: <83tymppj62.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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1282307150 4348 80.91.229.12 (20 Aug 2010 12:25:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 20 Aug 2010 12:25:50 +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 14:25:47 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 1OmQfK-0001Dg-Qd for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 14:25:47 +0200 Original-Received: from localhost ([127.0.0.1]:51100 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmQfJ-0007pG-Jz for ged-emacs-devel@m.gmane.org; Fri, 20 Aug 2010 08:25:45 -0400 Original-Received: from [140.186.70.92] (port=52751 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OmQfE-0007oX-73 for emacs-devel@gnu.org; Fri, 20 Aug 2010 08:25:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OmQfC-0000An-F8 for emacs-devel@gnu.org; Fri, 20 Aug 2010 08:25:40 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:38138) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OmQfC-0000Aa-6b for emacs-devel@gnu.org; Fri, 20 Aug 2010 08:25:38 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L7G00K00AGTOF00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 20 Aug 2010 15:25:16 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.220.100]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L7G00J1BAI0WNC0@a-mtaout20.012.net.il>; Fri, 20 Aug 2010 15:25:14 +0300 (IDT) In-reply-to: <87zkwhtws5.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:128914 Archived-At: > From: "Stephen J. Turnbull" > Cc: Andreas Schwab , > jan.h.d@swipnet.se, > monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Fri, 20 Aug 2010 19:15:38 +0900 > > Eli Zaretskii writes: > > > Plus, pushing many unrelated commits has a drawback as not showing > > in "bzr log" unless you also use the --include-merges (or -n0) > > switch, which makes "bzr log" significantly slower. > > No. Push simply synchronizes the histories, and IIRC to push in bzr > you must be a superset of the remote repo's history. So what > matters to the bzr log view is how you manage your local repo 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. > You may need to rebase if somebody sneaks in a commit before you > start your push With the rate of commits to the Emacs repository, the chances that someone "sneaks in a commit before you start your push" are 100%. We have committers in all time zones, so there's no time that you are safe. > 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. 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. 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, even if it faster (which I very much doubt). > 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). The workflow is much simpler, though. That's why this is what I do when I work on something that is not a 5-min job.