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

[Adrian Buehlmann]

On 2015-10-15 01:40, Gregory Szorc wrote:
> On Wed, Oct 14, 2015 at 4:31 PM, Adrian Buehlmann <adrian at cadifra.com
> <mailto: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).

This sounds a bit like a contradiction to me... ("You can already do
this" vs "Although, it doesn't work...")

If it doesn't work, then it should probably be fixed to work with these
kind of bundles?

These kind of bundles can't be applied to a non-empty repo, so it seems
to me that trying to make the unbundle command work with these is a bit
of a misfit.

The error message in the case below just looked a bit silly to me.. The
next question then was: Why add support for these kind of "bundles" to
the unbundle command, if they can only be used on empty repos? If you
start doing that (adding support for these kind of bundles to the
unbundle command), you will have to support it forever...

>     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.

As I understand the matter, these new "full (streamclone) bundles"
aren't really bundles to me. They can never be used like a classic
bundle. What can you do with such a full bundle? The only command that
makes sense is clone: Transform it into a new repo.

But perhaps I'm missing your point here, as I'm mostly sitting on the
fence. I got (unwillingly) involved into the business of streamcloning
because streamcloning ('hg clone --uncompressed') was the preexisting
feature which made the fncache file (.hg/store/fncache) necessary. Which
in turn was used as the name of the new repo format that I helped
introduce quite a while a ago. The only purpose of that repo format was
to limit the length of path names under .hg/store, which was biting us
on Windows. I then got bitten again when Bryan and myself tortured each
other with translating "my" horrible store._hybridencode function into C
code, which he found to be needed, because it turned out to be too slow
for his important use case. Yikes.

Now I see you inventing a new kind of bundles out of this streamclone
stuff. Which is quite interesting.