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: bzr repository ready? Date: Tue, 24 Nov 2009 10:33:50 +0900 Message-ID: <87ocmspuyp.fsf@uwakimon.sk.tsukuba.ac.jp> 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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1259026089 28667 80.91.229.12 (24 Nov 2009 01:28:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 24 Nov 2009 01:28:09 +0000 (UTC) Cc: 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 Tue Nov 24 02:28:02 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 1NCkCH-0002TI-Ja for ged-emacs-devel@m.gmane.org; Tue, 24 Nov 2009 02:28:01 +0100 Original-Received: from localhost ([127.0.0.1]:56158 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCkCG-00026m-EB for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 20:28:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCkCB-00026M-6b for emacs-devel@gnu.org; Mon, 23 Nov 2009 20:27:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCkC6-00025d-DL for emacs-devel@gnu.org; Mon, 23 Nov 2009 20:27:54 -0500 Original-Received: from [199.232.76.173] (port=57191 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCkC6-00025a-9u for emacs-devel@gnu.org; Mon, 23 Nov 2009 20:27:50 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:34868) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCkC2-0000tl-N7; Mon, 23 Nov 2009 20:27:47 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id DE2B2820D; Tue, 24 Nov 2009 10:27:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 47F281A28C6; Tue, 24 Nov 2009 10:33:50 +0900 (JST) In-Reply-To: <83d439nicw.fsf@gnu.org> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by monty-python.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:117655 Archived-At: Thansk for the review, Eli! Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > If you are a committer, you will want to use a bzr+ssh URL instead: > bzr+ssh://bzr.savannah.gnu.org/sources/emacs/trunk. > > Doesn't this URL require a savannah username somewhere in it? Dunno. Probably, but somebody who knows how Savannah works needs to fix that up. (Karl actually wrote that URL, but IIRC he's not a Savannah user, either. I bet he did what I would have done: substitute "bzr+ssh" for "http" in the http: URL.) > This first checkout may take many minutes. > > It's unclear to what command this refers: none of them mentioned any > "checkouts". Fixed on the wiki. > If there are other branches you'd like to mirror ... > > Question: doesn't the local repository we just created include all the > branches anyway? Not as described in the wiki. IIRC, there is currently no straightforward way to mirror a whole bzr repository (except rsync and/or tar), although the developers have made some noise about "doing something". When the wget+tar method gets straightened out, at least that way will exist. > Didn't someone say that the repository allows working off-line? Of course! > if so, it should include all the branches in the master repository, no? Maybe. It's not clear (eg, there's my discussion with Stefan about where to put "sandbox" branches---they could go in the master repository). > 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. I've made some changes, but I'm not real confident they address the confusion. > Is ``dedicated branch'' what is later described as ``feature > branches'' or something else? Something else. Rephrased to "branch dedicated to small changes". > 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. However, in the context of a particular workflow, a collection of trees, repositories, and branches will be associated with each other. > 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. > Once you have completed the task, you'll want to send it > upstream. You do this just as you would for a quick fix ... > > 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. > Finally, it looks like the TBDs near the end can be simply deleted > now, as what's before covers that turf already. I thought about it, but there is too much history of bitching about bzr performance (on bazaar@canonical and on the 'net in general, I'm not referring to the discussion here) to ignore: people *will* want "efficient" ways to use Bazaar. I decided to recommend stacked branches (sort of like a lightweight checkout, but all commits are local until you explicitly merge), which are very efficient at creation, and only accumulate history after creation. The advantage over checkouts is that someone who goes ahead and edits the working tree can commit locally and "bzr send", as described elsewhere in the document. I did delete the "Merging packages" and "Emacs releases" sections, as I think they're out of scope. Since they didn't contain any useful content, we're losing nothing until someone who needs that knowledge asks for it.