Performance of bzr update for lightweight checkout

[Eric Siegerman]

On Sat, 2011-02-05 at 15:28 +0200, Eli Zaretskii wrote:
> Date: Sat, 5 Feb 2011 14:13:20 +0100
> > From: Ulrich Mueller <ulm at gentoo.org>
> 
> > And as I said before, for lp:emacs it was only 15 minutes.
> 
> But that one is not necessarily up to date.

I don't know why the download times from Launchpad and Savannah
are so different, unless, as has been suggested, it's a simple
lack of resources at their end.  Actually, here's another stab in
the dark: I wonder if Savannah is running a pure-python bzr,
without the compiled extensions.  Would that account for such a
large speed difference on this particular operation?

Regardless, here's a workaround.  For the initial download, do:
    # Acceptably fast, but possibly out of date
    bzr branch lp:emacs emacs-branch

    # Sync with Savannah
    cd emacs-branch
    bzr pull --remember --overwrite \
        bzr://bzr.savannah.gnu.org/emacs/trunk

The "pull" should go quickly, since you'll already have most of
the revisions locally.  The "--remember" option says to make the
Savannah branch, not the LP one, our local branch's parent for
future pulls.  Thus, future updates can be done by a simple:
    cd emacs-branch
    bzr pull            # Do *not* use --overwrite here

"--overwrite" says to blow away any revisions that our branch has
but the pull source doesn't; it therefore guarantees us a
pristine copy of Savannah's trunk, even if the LP mirror has
revisions that haven't yet made it upstream.  IME one *very*
rarely wants to do this, but this is one of those times.  We
don't want the state of the LP branch; we're only using it as an
optimization, to seed the local revision store.

To be honest, I don't know whether the LP branch *can* have extra
revisions; I've never used LP on a project that's mirrored from
elsewhere.  But since the situation is easy to guard against, and
there's no down-side, it doesn't hurt to take the precaution.

The reason we specifically don't want "--overwrite" for
subsequent updates is that it would blow away any revisions the
Gentoo user might have committed locally.  They shouldn't do
that; they should use another branch, not the pristine mirror of
upstream that the ebuild maintains.  But if they do make that
mistake, omitting "--overwrite" will let us fail safe (bzr will
complain that a merge is needed) rather than silently clobbering
their changes.

  - Eric