[PATCH] Branch and pull-- now with remote

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> In general this works pretty well. I'm pretty sure you've seen my
> discussions about performance, and certainly that could be improved.

You bet.  The things I'd like to see are
1. Central stores.

This wouldn't help with the initial download, but would prevent
redundant downloads.  For example, if I had Martin's tree, and I wanted
to get your branch of his tree, I'd only have to download the texts and
revisions that were unique to your tree.

2. Redundancy elimination

We currently download each revision twice-- at the beginning, to find
out its inventory id, and at the end, to put it in the revision store.
I suspect doing this correctly requires creating a temporary store.

3. Anti-latency tactics.

Especially for the initial download, a major part of the problem is the
constant, serial, request-pause-response cycle.  Either pipelining or
parallel downloading can be used to keep the pipe full almost all the
time.  Given pipelines or parallel downloads, we can cut it down to four
server round-trips without breaking a sweat (1 to retrieve the history,
1 to retrieve all the revisions, 1 to retrieve all the inventories, 1 to
retrieve all the texts).

> One issue that I found is that "bzr branch" doesn't preserve the
> permissions of the files. So using bzr branch makes bzr lose it's
> execute permission.
> 
> I believe this is mostly because bzr doesn't actually track file
> permissions yet, is that true?

That's right.  Actually, Martin was only planning on tracking the
execute bit.

> This happens both with local branching, and with remote branching.

Both local and remote branching use the same technique to produce the
working tree:
merge ./@ ./@0

I.e. a three-way merge where OTHER is the latest revision, and BASE is
an empty tree.

Since there isn't any data about permissions in the inventory, merge
can't reproduce the execute bit.

But locally, just use cp -a.  It's faster, and bzr was designed to
support that.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnjhh0F+nu1YWqI0RAhfKAJ9YUycWAlfnPZe2p1Ntntrt9DLOogCffrkz
4lIX9ZjiZIeT8bjrE5tMODY=
=VXWE
-----END PGP SIGNATURE-----