[merge] Repository.tarball hpss command

[Martin Pool]

On 4/18/07, John Arbash Meinel <john at arbash-meinel.com> wrote:

> This probably has a net loss for local branching. Since you have "copy
> to temp, create tarball, bzip tarball, copy over the wire, unpack into
> temp, copy from temp to target".

Over tcp to localhost (about the worst case) this is indeed about
three times slower than the previous operation, which tells us that
the dominant effect is the actual repository copying - sending the
transport operations over tcp are not very significant.  It's three
times because in the current code we do copy the repository three
times: once into a temporary directory on the server, then it's
expanded into a temporary directory on the client, then it's installed
into the final destination.

In many cases we can avoid the temporary directories on both the
client and server if we know we want the whole thing and that we're
creating a new repository.  In that case it might be not much slower
locally and much better on high latency links.

I would really like to land this but in view of the time in this
release cycle maybe it should be held over rather than rushed, if
there is potential to slow things on fast networks.

We would still have to do something about making sure the protocol
handles transfer of large single requests without holding them in
memory.  Andrew, Robert and I might work on that tomorrow.

> My understanding of 'fetch' versus 'copy_content_into' is that
> 'copy_content_into' was meant to make the target identical to this (sort
> of like clone) including overwriting whatever was already there. (So it
> sets things like 'no-working-trees', 'shared-storage', etc).
>
> Versus "fetch()" which is just meant to fetch revision information and
> store it. It also has the directions turned around
> "source.copy_content_into(target)" versus "target.fetch(source)".
>
> I think that means that 'fetch()' thinks of 'target' as local and source
> as remote, I'm not sure if 'copy_content_into' thinks of source as local
> or not.

OK, I started cleaning this out.  I think copy_content_into really can
be removed in favour of just explicitly saying when we want the
settings to be copied, which should be rarely.

-- 
Martin