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 03:06:33 +0900 Message-ID: <87einpf74m.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258999692 8479 80.91.229.12 (23 Nov 2009 18:08:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 18:08:12 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 19:08:04 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 1NCdKV-0005iE-NC for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 19:08:03 +0100 Original-Received: from localhost ([127.0.0.1]:49321 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCdKV-0005gZ-6u for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 13:08:03 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCdDH-00010K-PH for emacs-devel@gnu.org; Mon, 23 Nov 2009 13:00:35 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCdDC-0000xh-8b for emacs-devel@gnu.org; Mon, 23 Nov 2009 13:00:34 -0500 Original-Received: from [199.232.76.173] (port=37208 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCdDB-0000xV-SN for emacs-devel@gnu.org; Mon, 23 Nov 2009 13:00:29 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:38055) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCdDB-0005Om-2c for emacs-devel@gnu.org; Mon, 23 Nov 2009 13:00:29 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id 96A831535AC; Tue, 24 Nov 2009 03:00:24 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5F4BD1A28C6; Tue, 24 Nov 2009 03:06:34 +0900 (JST) In-Reply-To: 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:117603 Archived-At: Stefan Monnier writes: > > "emacs" trunk branch). I think it's worth planning for that > > possibility in structuring the Emacs Bazaar repository. > > You mean the main repository should not be directly at .../srv/bzr/emacs > but at .../srv/bzr//emacs ? I think I agree. I'm not entirely sure what I mean. I've pretty well convinced myself there's no big efficiency issue in having "sandbox" branches in with the emacs-repo tarball, but maybe you want the tarball to omit their directories (as well as being treeless). > I can think of only 3 useful starting points: > 1- lightweight checkout: for people who only want to fetch the latest > code but will never need/want the diff/log or contribute code. This is easy (although we haven't written it up yet). > 2- bound branch (aka heavyweight checkout): for people who are happy > with CVS and will never want to create a local branch. I don't think bound branches should be encouraged in Emacs. YMMV, but I think in most loosely organized projects they're a worst practice. > 3- a local mirror-branch + a local dev branch. > > If you want something fancier than (3), read the Bzr docs. Well, Karl already added a description of feature branching, and I've done a bit of work on that too. (In fact, the editorial equivalent of open heart surgery -- as academic acknowledgments say, "any remaining badness is all mine", you can't blame Karl.) I'm reasonably satisfied that it would not be a waste of your time to review it at this point (and I'm looking forward to Eli's opinion, I'm hoping he'll find it useful). > I'm not actually convinced that (1) and (2) are really that important, > so maybe we could drop one of them (or maybe both of them even). > But the hard part is to integrate those 3 starting points with the > "wget+untar" approach. Well, if you want that added to the wiki, it's not hard to explain how to move any local changes from either a checkout or a branch into a new shared repo. I'm kinda hoping that people will follow instructions, and not go in for target practice on their feet---it should be unnecessary.