RFC: A mercurial pack extension

[Mark Williamson]

> > It took me a while to hunt down `--base null` too, at the time.
> > However, since `hg help bundle` at last tells you to use `--base null`
> > to get a full bundle, maybe adding another command is going too far
> > here? Especially as, at least in the way we did it, doing a full
> > bundle is rarely needed by a newcomer to a project. They rather
> > contribute partial bundles against the existing base. I do like `hg
> > bundle --full` as suggested by Mark, though.
>
> Argh. I've got 0.9.5 here and didn't know what you were talking about until
> I cloned crew. Hey, at least using the pack command saves you from typing
> 12 more characters.

Ah, when I read your patch I hadn't realised that --base null was a post-0.9.5 
addition.  Still I think that syntax isn't as intuitive as it could be, which 
is why I still like the idea of having a more explicit way of saying "get me 
a bundle with all the history".

> I agree with using partial bundles or patches for subsequent contributions.
> The use case I was thinking of involved someone who has no way to share
> their data with ssh or http+cgi and who wishes to share their hg repo with
> others. They could send the bundle over email, ftp, Instant Message
> file-sharing, torrent, or whatever.  I was also archiving some of my
> one-off projects and was making .tar.gz files until I realized that using
> bundles could save me disk space, plus I could just do a `hg -R
> /usr/archive/bundle.hg tip` to get at metadata I'd have to untar a tarball
> to get at.

Exactly.  Bundles *are* really cool and it'd be nice to be able to use them 
for more stuff than currently possible.

> The thought crossed my mind, but I put it off for now because I felt I
> couldn't reliably detect if the url was a bundle or a repository. Problem
> is there isn't a good way to stop people from naming their repos project.hg
> even if it's not a bundle. How about adding a -b, --bundle option to clone,
> it's still explicitly specifying a bundle but without using funny url
> syntax?

I name all my repositories with a  .hg so that I'll know they're not normal 
directories.  I guess this makes me a part of the problem here ;-)

To detect if a URL is intelligent HTTP or static http I tried sending a 
command to the server ("heads"), if that failed, I fell back to static http.  
I think the static http code determines if there's an hg repo there by 
looking for a .hg directory.

First part of detecting a bundle would be to test whether the URL points to a 
file.  Then, a bundle has "HG" as its first two characters, followed by some 
more characters indicating the bundle type.  If you wanted to determine 
whether a file on an remote server was a bundle, you could download the first 
few characters and check these for whether it's a (supported) bundle file, 
then continue the download if so?

> > Maybe an option to upload to some standard protocols could be added to
> > bundle, too? Like
> >
> >   hg bundle ftp://my.host.com//hgbundle/myproject-peo.hg ../base
> >
> > where ../base is my local clone of myproject-base.hg. Of course, one
> > could also use a tag for this. Might be especially handy if the
> > [paths] from .hgrc would work here.
>
> Sounds interesting. I'd have to poke at the capabilities that urllib2 gives
> us for uploads. FTP shouldn't be too difficult even if we need to pull in
> an extra module from python's std lib.

I imagine the ability to automatically upload bundles (e.g. over FTP, SSH or 
even HTTP to a server) could be useful for those who don't have easy access 
to CGI and end up doing everything via bundles?  It'd be quite neat 
useability-wise to be able to do something like this...

I actually wonder if it'd be technically possible to extend an existing 
bundle, which could make "push" to a bundle a sensible operation...  I can 
dream ;-)

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)