[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.
/Sune
More information about the Mercurial-devel
mailing list