[PATCH 00 of 12] RFC: Overlay repositories

[Alexis S. L. Carvalho]

Thus spake Brendan Cully:
> On Monday, 08 January 2007 at 10:00, Brendan Cully wrote:
> > On Wednesday, 03 January 2007 at 20:17, Alexis S. L. Carvalho wrote:
> > > I'm a bit worried about the robustness of an overlay repo:  since
> > > revlogng stores the revision number of the parents (instead of their
> > > nodes), an overlay repo depends not only on the set of nodes of the
> > > parent repo, but also on their order.  If you accidentally remove the
> > > parent, you may have a hard time "re-overlaying" the repo, even if you
> > > have another repo with all the necessary revisions.
> > 
> > that is true, but I'm not sure how much of a concern it is. In general
> > I'd expect the parent repository to be some fairly stable tree if it's
> > going to share several children (eg main or crew). It would be
> > possible to use a different index format for overlays, where the
> > parents are specified by node. That'd make the index bigger, but maybe
> > it's not a big deal since overlays only carry some small part of the
> > total history. Is it worth it?
> 
> It also occurred to me that in the event you need to rebuild the
> parent, you could probably find the nodes by walking the parent
> changelog backward and trying the nodes found as candidate parents,
> then recomputing the hashes of the nodes in the children to see if
> they match. I think you'd be able to get everything but the order of
> the parents for merges, which I'd guess would be fine.

Hmm...  yeah, that should take care of relinking the revlog.  It
probably won't be very cheap, but this shouldn't be a very common
operation.

Alexis