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:40:57 +0900 Message-ID: <873a48djpi.fsf@uwakimon.sk.tsukuba.ac.jp> References: <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> <877htl53tc.fsf@telefonica.net> <83einsozea.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 1258814133 11435 80.91.229.12 (21 Nov 2009 14:35:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Nov 2009 14:35:33 +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:35:26 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 1NBr32-0005uY-BK for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 15:34:48 +0100 Original-Received: from localhost ([127.0.0.1]:49817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBr31-0006ef-Ty for ged-emacs-devel@m.gmane.org; Sat, 21 Nov 2009 09:34:47 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NBr2v-0006eD-Hp for emacs-devel@gnu.org; Sat, 21 Nov 2009 09:34:41 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NBr2r-0006c6-DL for emacs-devel@gnu.org; Sat, 21 Nov 2009 09:34:41 -0500 Original-Received: from [199.232.76.173] (port=57319 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NBr2q-0006bx-Uu for emacs-devel@gnu.org; Sat, 21 Nov 2009 09:34:37 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:50972) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NBr2n-0007O3-PA; Sat, 21 Nov 2009 09:34:34 -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 D1C111537B4; Sat, 21 Nov 2009 23:34:31 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0C8E41A2609; Sat, 21 Nov 2009 23:40:58 +0900 (JST) In-Reply-To: <83einsozea.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:117445 Archived-At: Eli Zaretskii writes: > But the EmacsWiki page does use the "lightweight branch" terminology. > Should it be corrected? Yes. > > A non lightweight checkout supports committing changes without sending > > them to the parent branch, using a command line option. > > When and why would this be useful? It's useful for splitting your history into bite-size, coherent pieces that you aren't ready to push to the mainline. For example, you might add an argument to foofunc in foo.el, and fix all the calls in core Lisp. Now you commit. Next you go through all the packages, and fix them up too, with a separate commit to each one, because you're not as sure you understand the code in each one. This allows you to add a comment explaining your uncertainty to the commit log, or have the package's principal maintainer veto that commit only while everything else goes through. Then you cd to your local copy of the mainline branch, merge that branch into it, and push to the public repo. By default bzr log will show only that the whole branch got merged, but someone who is curious can see the detailed history. > > A lightweight checkout does not support this because it lacks the > > local VC data. > > Would a lightweight checkout from the master repository be a good idea > for people who do not intend to send patches, just build the current > development version? Yes. I take back what I wrote in my previous response; this is indeed an *excellent* third reason for lightweight checkouts, probably much more important than "casual contribution". > > Actually, a non lightweight checkout is what Bazaar calls a bound > > branch. You can unbind a non-ligthweigth checkout anytimme for > > converting it to a regular branch and you can bind a branch to some > > other branch to convert it to a checkout of that branch. > > So checkouts and branches are mostly the same? No. In principle, a checkout is not a branch at all. It contains the working tree, but no history, and by default only enough metadata to tell bzr which repository to get history and other metadata from. Since the parent repository may be on another host, "log", "diff", and "commit" become expensive operations, and pull and push are no-ops. On the other hand, a branch *is* a line of historical development. It is the history. The working tree is optional (and some workflows use shared repositories that contain only treeless branches). A "bound branch" used to be called a "heavyweight checkout", the idea being that most of the time you operate as a checkout but when necessary (you're on the train, your ISP is taking a siesta), you have a local cache of history. That turned out to be a bad idea. To the extent that you actually use the local cache, it turns out to be a quite different workflow from the (lightweight) checkout in practice. Some people are still fans of bound branches, but it's a specialized workflow. The general trend is away from them. The "heavyweight checkout" terminology is severely deprecated, and you won't see it on bzr channels any more.