[PATCH 4 of 4 RFC stream clone bundles] commands.unbundle: support consuming streaming clone bundles

[Gregory Szorc]

On Wed, Oct 14, 2015 at 4:31 PM, Adrian Buehlmann <adrian at cadifra.com>
wrote:

> On 2015-10-15 00:34, Gregory Szorc wrote:
> [..]
> > +We can unpack packed1 bundles
> > +
> > +  $ hg init packed
> > +  $ hg -R packed unbundle packed.hg
> > +  6 files to transfer, 2.55 KB of data
> > +  transferred 2.55 KB in *.* seconds (*/sec) (glob)
> > +  (run 'hg heads' to see heads, 'hg merge' to merge)
> > +
>
> Potentially stupid idea:
>
> Why not implement a special form of the clone command, which reads from
> such a full "bundle" file and creates the repo from that bundle?
>
>    $ hg clone packed.hg packed
>

You can already do this! Although, it doesn't work with this new bundle
type because you need to teach bundlerepo.py about different bundle types
(it's also broken for bundle2 currently).


>
> I don't know if - alternatively - some new option would be needed. Maybe
> like this:
>
>    $ hg clone --unbundle packed.hg packed
>
> > +We can't unpack packed1 bundles on non-empty repos
> > +
> > +  $ hg -R packed unbundle packed.hg
> > +  abort: cannot apply stream clone bundle on non-empty repo
> > +  [255]
> > +
>
> ..which then could not happen any more
>

This touches on the subject of whether streaming clone / packed bundles are
or aren't bundles. I could argue both perspectives. But if they aren't
bundles, then we need to invent new commands and figure out a way to
shoehorn them into the new clone bundles feature. I think I'm fine with
either way: I just care most about getting streaming clone support into the
clone bundles feature otherwise the feature is useless for Mozilla's
automation needs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20151014/61b68bc7/attachment.html>