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: Emacs source snapshots Date: Thu, 05 May 2011 13:50:08 +0900 Message-ID: <87pqnx69a7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1304501969.6763.1448069069@webmail.messagingengine.com> <20110504194551.GA4080@netbook> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1304570655 30587 80.91.229.12 (5 May 2011 04:44:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 5 May 2011 04:44:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Grigorios Bouzakis Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 05 06:44:11 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QHqQ6-00022T-Q3 for ged-emacs-devel@m.gmane.org; Thu, 05 May 2011 06:44:10 +0200 Original-Received: from localhost ([::1]:54107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHqQ5-0005sa-V0 for ged-emacs-devel@m.gmane.org; Thu, 05 May 2011 00:44:09 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39771) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHqQ2-0005qM-CZ for emacs-devel@gnu.org; Thu, 05 May 2011 00:44:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QHqQ1-0003yg-Ih for emacs-devel@gnu.org; Thu, 05 May 2011 00:44:06 -0400 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:48519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QHqQ1-0003tI-3E for emacs-devel@gnu.org; Thu, 05 May 2011 00:44:05 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id CBD373FA06C8; Thu, 5 May 2011 13:43:51 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5AC1711F2A5; Thu, 5 May 2011 13:50:08 +0900 (JST) In-Reply-To: <20110504194551.GA4080@netbook> X-Mailer: VM 8.1.93a under 21.5 (beta30) "garlic" f2881cb841b4+ XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139133 Archived-At: Grigorios Bouzakis writes: > I am aware of --depth. But as far as i know thats valid only for the > initial cloning. But cloning the repository a second time to update the > source tree will add commit history since the first clone was > made. True. However, if you have enough space to build Emacs comfortably, you don't need to worry about taking up tons of extra space for a while (a few hundred or thousand commits). While the proponents of the various VCSes will argue about which is most space-efficient, they are all very space-efficient. > I am not entirely sure about bzr checkout --lightweight but it > seems to work the same way. No, it doesn't. bzr has a plethora of options for connecting workspaces to repositories. A lightweight checkout really is a checkout in the sense you are used to with CVS or Subversion: there is no repository local to the checkout and *all* version information is kept in the source repository, except for a simple pointer to the currect version that is checked out. This means that all operations that refer to versioning require communication with the repository. I have seen reports recently on the bazaar list that use of a lightweight checkout over the network requires an inordinate amount of bandwidth, but even so it may be worth while for your usage. (Lightweight checkouts were originally designed for use with local shared repositories as a fast way of switching among branches in a single workspace, and are not optimized to minimize I/O.) The other main forms of "checkout" in bzr are: (1) *stacked branches*, which are similar to git limited-depth checkouts in that they only store the most recent versions locally, but they really are full service branches (they will go out and get version information from the parent when necessary). (2) *bound branches* (aka heavyweight checkouts) which requires a full local repository (all versions stored), and keep the local and remote repositories in full sync at all times. (3) *standalone branches* which maintain a full local repository but may diverge from the remote repository as appropriate for developers.