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: Mon, 23 Nov 2009 16:35:47 +0900 Message-ID: <87r5rpsnfw.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> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1258961475 12438 80.91.229.12 (23 Nov 2009 07:31:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2009 07:31:15 +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 08:31:08 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 1NCTO4-0001N5-O6 for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 08:31:05 +0100 Original-Received: from localhost ([127.0.0.1]:33353 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCTO4-0000hy-8D for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2009 02:31:04 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCTMl-0000NM-Cf for emacs-devel@gnu.org; Mon, 23 Nov 2009 02:29:43 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCTMg-0000JP-V5 for emacs-devel@gnu.org; Mon, 23 Nov 2009 02:29:42 -0500 Original-Received: from [199.232.76.173] (port=59350 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCTMg-0000J4-Ko for emacs-devel@gnu.org; Mon, 23 Nov 2009 02:29:38 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:33194) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCTMf-0007Uw-KT for emacs-devel@gnu.org; Mon, 23 Nov 2009 02:29:38 -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 E6CD1820D; Mon, 23 Nov 2009 16:29:34 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0D4D91A28C6; Mon, 23 Nov 2009 16:35:48 +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:117569 Archived-At: Stefan Monnier writes: > I think we should only consider setups that are close to what was done > with CVS. After that, people can read the Bzr docs to figure out what's > best for them. FSVO "close to CVS." Specifically, I *strongly recommend* that all workflows recommended to core developers start by creating a local repo (try that in CVS! :-). Questions for those who have actually used bzr on the emacs repo (for the moment, I'm not interested in GPLv3 code but we're working on that :-): 1. Jason's suggestion of "bzr init-repo --no-trees -2a" sounds like a good idea to me for performance reasons. Is this going to be entirely superseded by the "wget; tar x" workflow? N.B. Many projects that convert to dVCS start to proliferate "sandbox" branches, cf. http://code.launchpad.net/mailman/ or http://git.kernel.org/. I *think* that if the same base URL is used to host such sandbox branches, it won't cause any problems for the "wget; tar x" workflow" (you just do tar c only on the "emacs" trunk branch). I think it's worth planning for that possibility in structuring the Emacs Bazaar repository. 2. I think that all core developer workflows we recommend *at this point in time in the wiki page* should start with "bzr branch trunk" (not usual in CVS but I think the rest of the workflow is reasonably close to CVS). I recommend exactly two variants: a. A generic "dev" branch for small one-off fixes. I recommend the branch name "quickfixes" or something like that instead, to more precisely indicate the purpose of the branch. I would do this kind of work directly on a trunk checkout in CVS. b. Feature branches for any work that might involve concurrent commits in other branches you're working on locally, or might span several updates from upstream. I would do long-running tasks with many commits on a branch in CVS, while relatively short tasks (which nevertheless span multiple updates from upstream for whatever reason) would be done in the trunk checkout. The latter half I consider suboptimal though, and I hope people transitioning from CVS would find it as natural as I do to crank the threshold for feature branches way down. 3. How do people organize their branches (bound or not) and (lightweight) checkouts? Eg, for my desultory work on GNU Mailman, I have Mailman -+- 3.0 # all toplevel branches are mirrors | # and are configured treeless +- 2.2 # defunct | +- 2.1 | +- work -+- 3.0 # all local branches and checkouts | # will be placed under work/ | # work is an ordinary directory | # 3.0 is also registered on Launchpad[1] +- lilfix # these are both branches; "lilfix" # is a historical relic, I think # "quickfixes" is a better generic # recommendation Footnotes: [1] I don't know if "registering a branch" has a corresponding feature on Savannah, but I thought I should mention this fact.