Matt Mackall mpm at selenic.com
Fri Sep 9 02:48:24 CDT 2005

On Thu, Sep 08, 2005 at 11:10:59PM -0700, TK Soh wrote:
> --- Matt Mackall <mpm at selenic.com> wrote:
> > The bundle command finds all the changes that are not in the remote
> > repo, generates a changegroup identical to the one used in the wire
> > protocol, compresses it with bzip2, and writes it into the specified
> > file.
> > 
> > This file can then be transferred with traditional means (email
> > attachment, FTP, scp, http, etc.) and will preserve all the changeset
> > information for later application with the unbundle command.
> I've been trying to fit bundle-unbundle into our development environment, but
> so far couldn't really get a good picture worked out. Perhaps you can provide
> some hint on the usage pattern with these two commands? FYI, we do cross-site
> development, but can only share the work by tranfering the delta/repo through a
> central dropbox server, or emails. Unfortunately serving the repo by http will
> be relatively troublesome, as it requires root permission. The repo sizes are
> usually in terms of hundred MBytes. 
> One problem I would foresee is that bundle needs to look at a reference repo to
> find the changegroups to generate, and the reference repo would mostly be a
> remote one. Of course we may create local references, but this may be an issue
> due to the size of our repos, and other overhead in maintaining them.
> Comments?

Well that's all very strange but something like the following should

Each client keeps a pristine copy of the upstream repo and works off a
clone. The mirror repo is kept in sync by grabbing daily bundles.

Bundles to send upstream are created by comparing the clone against
the local repo.

The plan is to also add -r options to bundle so that you can do
exports without reference to the remote repo.

Mathematics is the supreme nostalgia of our time.

More information about the Mercurial mailing list