linkrevs and evolve plan?

[Matt Mackall]

On Tue, 2014-11-18 at 13:19 -0800, Augie Fackler wrote:
> 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?

Probably. But I think we have to transition from "linkrevs are
authoritative" to "linkrevs are hints to a higher-level API that
everything else uses" first.

-- 
Mathematics is the supreme nostalgia of our time.