Re: Emacs source snapshots

["Stephen J. Turnbull" <stephen@xemacs.org>]

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.