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: Sat, 21 Nov 2009 23:17:21 +0900 Message-ID: <874ooodksu.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <837htkoxy8.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1258812679 7738 80.91.229.12 (21 Nov 2009 14:11:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2009 14:11:19 +0000 (UTC) Cc: =?iso-8859-1?Q?=D3scar?= Fuentes , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 21 15:11:12 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 1NBqgA-0004xL-JL for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 15:11:10 +0100 Original-Received: from localhost ([127.0.0.1]:57218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBqg9-00026k-TX for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 09:11:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBqg4-00025c-VS for emacs-devel@gnu.org; Sat, 21 Nov 2009 09:11:05 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBqg0-00022W-Jb for emacs-devel@gnu.org; Sat, 21 Nov 2009 09:11:04 -0500 Original-Received: from [199.232.76.173] (port=35791 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBqg0-00022T-9q for emacs-devel@gnu.org; Sat, 21 Nov 2009 09:11:00 -0500 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:46971) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBqfx-0002fj-7g; Sat, 21 Nov 2009 09:10:57 -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 A57A8820F; Sat, 21 Nov 2009 23:10:55 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F34631A2609; Sat, 21 Nov 2009 23:17:21 +0900 (JST) In-Reply-To: <837htkoxy8.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:117444 Archived-At: Eli Zaretskii writes: > =D3scar Fuentes writes: > > Besides, using a shared repository is just a disk&time saving trick, it > > doesn't affect the workflow otherwise. N.B. This is false, even today. Bazaar now supports commands for interrogating the shared repository. The most important in daily use is "branches", which lists the branches currently available from that repository. > So when to use a shared repository and when not? (Core) Emacs developers will always want to use a shared repository. The penalty for using one for even a single branch is very small; as soon as you have more than one, time and disk savings build rapidly. The *only* times one wants to *avoid* use of a shared repository are (1) for casually browsing the source and related contributions (eg, you occasionally have one-line fixes), you plan to send patches to the developers for them, and you expect *never* to participate actively in project development; (2) when the project wishes to *enforce* a centralized workflow on the developers. Many important enhancements to bzr (like the "pipeline" add-on, which helps to manage a "stack" of patches, like Andrew Morton's famous "quilt" script) depend on "cheap branching", which shared repositories provide. I'm not going to go into details here, because you may not ever need those (and there are often alternatives), but having the shared repository available from the start makes life much more pleasant in many such scenarios.