[PATCH 4 of 7] filelog: add support for unpacking lwcopy entries

Sune Foldager cryo at cyanite.org
Wed Sep 15 05:59:48 CDT 2010

On 15-09-2010 10:11, Benoit Boissinot wrote:
> On Tue, Sep 14, 2010 at 11:56:33AM +0200, Sune Foldager wrote:
>> # HG changeset patch
>> # User Sune Foldager<cryo at cyanite.org>
>> # Date 1284157797 -7200
>> # Node ID a216867d6bb6f768ebeca2140d36c207e08264d1
>> # Parent  6d45223c5d5b9c6375f111d95ae711e689d0ecd1
>> filelog: add support for unpacking lwcopy entries
> I'm wondering, how much does it cost to duplicate the meta keys, put
> them in both the delta, and in the text (so no need to have the special
> handling to keep the order, and to remove "copylw").

Well, it costs my sleep at night, at least; that's worth something, 
isn't it? :-). I dislike the idea. The metadata is "copy: <path to 
original>", "copyrev: <not rev, but original node>" and "copylw: <empty 
string; no data needed>".

I immediately imagine another layer coming later on top of this (next 
time we need to tweak something in the filelog), and then repeating 
everything even more... I don't think it's the right approach. Metadata 
is kinda hacked on top as it is; going down this road would make it 
worse, IMHO.

Also, we diff against the parent's .read, not .revision. Parent might be 
a copy as well, so it might be a problem to diff against .revision 
(which certainly should be done, if we include the metadata; otherwise 
we diff different domains against each other).

In terms of performance, I don't think there will be much difference 
either way.


More information about the Mercurial-devel mailing list