linkrevs and evolve plan?

[Augie Fackler]

On Nov 18, 2014, at 11:32 AM, Matt Mackall <mpm at selenic.com> wrote:

> On Tue, 2014-11-18 at 11:02 -0800, Augie Fackler wrote:
> 
>> For our work on narrow clones, we've started dithering about how to
>> handle linkrevs if we allow the client to add files (which would
>> require adding extra changelog entries, probably in the middle of the
>> stream.) Matt and Pierre-Yves, did you ever discuss how you were going
>> to handle linkrevs for evolve, and is it possible that your solution
>> for this would help us avoid having to rewrite linkrevs in the
>> filelogs?
> 
> My plan is still to treat linkrevs as advisor and use something like the
> link corrector proof of concept I posted a while back to fix them up.

Hm, okay. I think for narrow (and probably also shallow) clones I want to add a layer of indirection so that we can prepend changes to the changelog without having to go and rewrite the linkrev in every filelog (basically, make the linkrev point into some kind of mapping, so that linkrevs don't have to point at the actual changlog rev for a given node.) Does that sound like something that might be workable?

> 
> -- 
> Mathematics is the supreme nostalgia of our time.
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141118/745a0d4a/attachment.pgp>