Seeking information about lightweight copying/renaming

Sune Foldager cryo at cyanite.org
Tue Apr 6 06:58:08 CDT 2010


I may not have read my mails the last week or so, so I have missed this 
lwcopy GSOC discussion. Last I checked, I was looking at 
pushing/preparing some more of the patches in the lwcopy queue to crew 
(but last time I checked, it was also a bit on hold pending some 
protocol issues which haven't been fully resolved).

Have there been any decisions on this that I missed? At any rate:

On 06-04-2010 05:51, Paul Malmsten wrote:
> - Is this a reasonable approach to solving the problem? Were there any
> major concerns with this approach which should be considered when
> planning future work?

I think the approach is deemed fine, overall. There are some bits 
missing of course.

> - Has any further work been done beyond that of the patches written by
> Murkt (linked above)?

Mainly at the planning level, at the 1.5 sprint. I rebased and fixed up 
the original patch queue, combined some smaller patches and pushed one 
out to the crew branch.

> - Would it be possible for a revlog with no data/diff (only copy/rename
> metadata) to cause problems somewhere by invalidating an assumption of
> no empty revlogs?

It should be fine, but I haven't thought about all details.

> - I took a look at the current copy tests (test-copy and test-copy2).
> For any new tests against revlog data, my thought is to continue the
> pattern of reading dumprevlog's output and md5summing the revlogs. Is
> this reasonable?

The lwcopy patches should make everything seem like normal to the tests 
we normally have in our suite, so if every existing test passes, it 
should be alright (assuming the existing tests cover enough).

> How pushing/pulling work:
> - How do they work for local vs. remote repositories? For local
> repositories, are the source/dest data files (for pull/push
> respectively) accessed directly?

Yes, for local repositories the invoked Mercurial program directly 
accesses the foreign repository the same way it accesses the local one.

> - For remote repositories, how does the wire protocol fit in? I dug
> around in the source code a bit for ssh and http syncing; at first
> glance, it seems like ssh syncing just runs an http sync over the
> tunnel, and the http code does all of the protocol work. Is that where
> most of the wire protocol is implemented?

No, not really. The protocol can conceptually be divided into two: The 
low-level or transport layer, and the high-level or command layer. The 
transport layers are different in the two (ssh and http), and will 
likely stay that way since there are pretty big differences in the 
underlying channels. The command layer is partially double-implemented 
right now, but that might change in the somewhat near future (since the 
same work is done pretty much in the same way).

/Sune


More information about the Mercurial mailing list