Seeking information about lightweight copying/renaming

[Paul Malmsten]

Hi Sune,

Thank you very much for your insight.

On Tue, Apr 6, 2010 at 7:58 AM, Sune Foldager <cryo at cyanite.org> wrote:

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


As far as I know, you haven't missed much of any discussion. I've just
recently been exploring the potential of picking up where previous
lightweight copy work left off as a GSoC project.

What were the protocol issues which prevented further progress?


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


What is your vision for how work should continue on the project? Would you
mind sending me a link to your work?

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


That's true, although some of the current tests md5sum the revlogs, so if
they are affected by a lightweight copy feature, they will need to be
updated. Also, my thought was to add one or more tests which verify correct
creation/reading of lightweight copy revlogs in isolation, perhaps with a
similar approach.

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

Ah, okay, the partial double-implementation threw me off a little. Thanks
for the clarification.


> /Sune
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20100406/59d5eedc/attachment.htm>