TK Soh teekaysoh at yahoo.com
Sun Sep 11 19:27:45 CDT 2005

--- Matt Mackall <mpm at selenic.com> wrote:
> 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
> work:
> 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.

Our repos can scale up to GBytes, so that maybe too expensive to implement.
Though that's indeed a way to workaround the problem.
> The plan is to also add -r options to bundle so that you can do
> exports without reference to the remote repo.

One concern I'd have is whether -r option would miss some branches that would
result in failure when unbundling on remote repo. Perhaps some kind of
changeset info can be generated from the destination repo, which can be used by
bundle in searching for the deltas? I think darcs is using some kind of context

Yahoo! for Good 
Watch the Hurricane Katrina Shelter From The Storm concert 

More information about the Mercurial mailing list