From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: bzr repository ready? Date: Sun, 22 Nov 2009 17:58:12 -0600 Message-ID: <87pr7a9kob.fsf@red-bean.com> References: <87vdhfpil2.fsf@red-bean.com> <87einvxy9c.fsf@red-bean.com> <20091118230952.GB908@muc.de> <87my2jw05z.fsf@red-bean.com> <83skc9pbf7.fsf@gnu.org> <87iqd5vw5n.fsf@red-bean.com> <877htl53tc.fsf@telefonica.net> <871vjs6ci7.fsf@telefonica.net> <87d43c4f1e.fsf@telefonica.net> <87ocmwtlbs.fsf@red-bean.com> <87tywnd4iw.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Karl Fogel NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258934356 25447 80.91.229.12 (22 Nov 2009 23:59:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2009 23:59:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 00:59:09 2009 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.50) id 1NCMKh-0005Y5-HQ for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 00:59:07 +0100 Original-Received: from localhost ([127.0.0.1]:43090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCMKh-0005FB-49 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2009 18:59:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCMJx-000528-1M for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:58:21 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCMJs-0004xU-HM for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:58:20 -0500 Original-Received: from [199.232.76.173] (port=57283 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCMJs-0004xA-2U for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:58:16 -0500 Original-Received: from sanpietro.red-bean.com ([66.146.206.141]:54967) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NCMJr-0004Wb-Jd for emacs-devel@gnu.org; Sun, 22 Nov 2009 18:58:15 -0500 Original-Received: from localhost ([127.0.0.1]:42910 helo=kfogel-work ident=kfogel) by sanpietro.red-bean.com with esmtp (Exim 4.69) (envelope-from ) id 1NCMJp-0005NY-6J; Sun, 22 Nov 2009 17:58:13 -0600 In-Reply-To: <87tywnd4iw.fsf@uwakimon.sk.tsukuba.ac.jp> (Stephen J. Turnbull's message of "Sun, 22 Nov 2009 05:08:55 +0900") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux) 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:117524 Archived-At: "Stephen J. Turnbull" writes: > Karl Fogel writes: > > > Everyone: > > > > It's a wiki. Please edit it :-). > > OK, I've done so :-). Please review my work, though; I'm far more > expert on git and VCS theory than I am on bzr pragmatics. > > Specifically, one small change was I glossed the difference between > the "dev" branch (one branch for sequences of small independent > changes), vs. the SOME-TASKNAME branch (of which there will be many, > each containing a set of related commits). For example, typically you > would delete a feature branch, but hang on to and reuse the "'dev" > branch. > > The more important one is that AIUI, pushing directly from > SOME-TASKNAME is a bad idea. Typically, you want to merge that branch > into trunk (the mirror branch), then commit (which automatically > pushes to upstream in the recommended setup as a bound branch). So just to make sure, when you wrote in the wiki "You can also just push it directly to the upstream master: bzr push bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk/" you were talking about running that from within branch SOME-TASKNAME, *not* from within the local trunk mirror, right? (It might be good to always wrap commands in 'cd foo; ...; cd ..' so the reader is absolutely clear on what's taking place where.) Right below that, I tweaked the explanation a bit; please review and see what you think. There is one sentence that still puzzles me; it now reads: "On the other hand, if you push directly from the ##SOME-TASKNAME## branch, your branch will be perceived as part of the mainline by ##bzr log##, while commits on the mainline (including merges from other developers and their detailed branch histories) will be hidden." I don't understand the second part. How will commits on the mainline be hidden? (That is, from whom will they be hidden, and in what situations?) > The reason is that you want something like this, which is how Bazaar > will present the merge and commit workflow: > > $ bzr log > 3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME > 2 Merge concurrent development > 1 Parent of SOME-TASKNAME > $ bzr log -n 0 > 3 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME > 3.3 Munge a bunch of fiddly little bits, all alike > 3.2 Merge from trunk > 3.1 Munge a fiddly little bunch of bits, all alike > 2 Merge concurrent development > 2.1 One big ol commit > 1 Parent of SOME-TASKNAME > [several hundred thousand fiddly commits elided] > > Not this, which is how Bazaar will present the "just push" workflow: > > $ bzr log > 5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME > 4 Munge a bunch of fiddly little bits, all alike > 3 Merge from trunk > 2 Munge a fiddly little bunch of bits, all alike > 1 Parent of SOME-TASKNAME > $ bzr log -n 0 > 5 Merge the fiddling-while-bits-rot branch aka SOME-TASKNAME > 4 Munge a bunch of fiddly little bits, all alike > 3 Merge from trunk > 3.1 Merge concurrent development > 3.1.1 One big ol commit > 2 Munge a fiddly little bunch of bits, all alike > 1 Parent of SOME-TASKNAME > [several hundred thousand fiddly commits elided] > > Note how the latter inflates the importance of individual commits from > SOME-TASKNAME, while confusing the timing with which various commits > landed on the trunk. (I'm not sure I got the above exactly right, but > such effects are definitely part of the way bzr log looks at the > branch's history.) Agreed. It might be better just to recommend the merge-and-commit workflow for *everything*, always, and let those who want to become Bzr Jedi Masters learn to do the "just push" on their own, when they are experienced enough to understand the consequences. Thoughts? -Karl