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: bzr repository ready? Date: Tue, 24 Nov 2009 02:28:56 -0500 Message-ID: References: <87zl6vskq0.fsf@red-bean.com> <874op07kb0.fsf@red-bean.com> <87639fr3w7.fsf@red-bean.com> <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> <87vdh29lfo.fsf@red-bean.com> <83k4xhoo0n.fsf@gnu.org> <87my2dhlko.fsf@telefonica.net> <87r5rpsnfw.fsf@uwakimon.sk.tsukuba.ac.jp> <87einpf74m.fsf@uwakimon.sk.tsukuba.ac.jp> <83d439nicw.fsf@gnu.org> <87ocmspuyp.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1259047755 5126 80.91.229.12 (24 Nov 2009 07:29:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 07:29:15 +0000 (UTC) Cc: 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 Tue Nov 24 08:29: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 1NCppk-0003oK-K7 for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 08:29:09 +0100 Original-Received: from localhost ([127.0.0.1]:36642 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCppj-0007Bc-RN for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 02:29:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCppd-0007BX-KU for emacs-devel@gnu.org; Tue, 24 Nov 2009 02:29:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCppb-0007B1-Bl for emacs-devel@gnu.org; Tue, 24 Nov 2009 02:29:00 -0500 Original-Received: from [199.232.76.173] (port=38358 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCppb-0007Aq-6f for emacs-devel@gnu.org; Tue, 24 Nov 2009 02:28:59 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:37866) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCppa-0001W8-PA for emacs-devel@gnu.org; Tue, 24 Nov 2009 02:28:59 -0500 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1NCppY-0006EX-07; Tue, 24 Nov 2009 02:28:56 -0500 In-reply-to: <87ocmspuyp.fsf@uwakimon.sk.tsukuba.ac.jp> (stephen@xemacs.org) 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:117663 Archived-At: > From: "Stephen J. Turnbull" > Cc: monnier@iro.umontreal.ca, > emacs-devel@gnu.org > Date: Tue, 24 Nov 2009 10:33:50 +0900 > > Thanks for the review, Eli! Thanks for writing that in the first place. > > Compared to CVS, these branches are lightweight --- it doesn't cost much > > to create them, as they're all sharing storage in the repository, and > > they can't bother anyone else. However, there is one "weighty" > > aspect: [etc, etc]. > > > This is confusing and looks like a merge of 2 different narratives. > > I'm not sure why you think that. That was my way of trying to figure out what possible line of thinking gave birth to that paragraph. Forget it, I try explain the confusion below in concrete terms. > > If the source tree is ``weighty'', then why are the branches > > ``lightweight''? > > In Bazaar, the working tree and the branch metadata are basically > independent of each other; they can even reside on different hosts, > and branches can even exist without working trees. Understanding this > is fundamental to designing efficient workflows for Bazaar. I'm not sure I understand this. With the commands described on the wiki, my understanding is that the history is in the `trunk' branch, which is a mirror of (some) branches in the master repository, while the source tree is in the development branches. Is that true? If this is true, then why does ``first bzr branch operation in a new repository [...] take many minutes''? It doesn't bring any source files, only the history, right? What brings the sources is the first development branch you create, in our case with these commands: cd $DEVHOME/emacs bzr branch trunk/ quickfixes/ Right? > > Why is it important that there will be no build products in the > > tree? etc. etc. > > That isn't obvious, even though I wrote "make bootstrap can take an > annoying amount of time"? I've fiddled with it a bit, but I don't > know what to say. If you still think it's confusing, I'll sleep on it > and try again in a day or so, or maybe Karl or a 3d party can do > something with it. It's probably my confusion. Let me take that paragraph apart and try to show why it confuses the heck out of me. I'm going to present a narrative of my thoughts as I read the current text: Wiki: Compared to CVS, a Bazaar branch is lightweight -- it doesn't cost much to create one, as all branches in the repository are sharing storage Me: So far, so good... Although it is not clear what storage is shared -- is it the sources that are common to all branches, the history, both? and they can't bother anyone else ??? what's this about? is it important? can it be deleted without sacrificing something important However, there is one "weighty" aspect: the source tree itself, which takes time to check out. okay, but when (at which time) does this weighty aspect rears its ugly head? Is it at each "bzr branch" time? Or does this happen only once? If the latter, which one of the commands shown is the one that will cost me? Even more important, *there will be no build products in the tree.* "More important" than what? Does this refer to the previous sentence or to the one before it? And what's with "no build products in the tree" -- ain't I building Emacs in place? Where will the products be, if not in the tree? make bootstrap takes an annoying amount of time. I knew that... That's why we recommend that for small changes you use and reuse a branch dedicated to such small changes. Does this "that's why" refer to the previous sentence about long bootstrap, or to everything else in this paragraph? IOW, the logical thread of thought from one sentence to the next is interrupted several times, and makes it hard to understand what the text says and to discern facts from their explanation and the recommendations. I'm still not sure I understand the intent, but let me try to rewrite this text assuming that I did understand: Bazaar allows all the branches in the repository to share storage, which makes the branches much more lightweight than CVS branches. However, it still takes time to checkout the source tree for each branch, and bootstrapping a new tree is annoyingly long. That is why we recommend that for small changes you keep reusing the same ``quickfixes'' branch. This way, once you bootstrapped the ``quickfixes'' branch once, the subsequent update, build, and commit steps of the update-edit-build-test-commit cycle will all be very fast, as long as you continue working in the same branch. Note that I didn't put the "there will be no build products in the tree" part anywhere, because my interpretation of the text (which is probably incorrect or incomplete) didn't suggest any good place for it. > > What about branches in the master repository? Unless I'm missing > > something, the described workflows don't cover that. What if I want > > to have my branch available from the upstream? > > What about them? The workflows don't cover them, and won't, until > there's a policy permitting/regulating "sandbox" branches. At this > point, only maintainers need to worry about them. This is not a > document for maintainers (until Stefan, Yidong, or a release engineer > they appoint asks for it). > > > (Release branches will need that, right?) > > Yes, but AIUI people who create release branches are not the target > audience of this document. I thought the document targets maintainers as well. Me, for example. Thanks.