[PATCH 00 of 12] RFC: Overlay repositories

Brendan Cully brendan at kublai.com
Tue Jan 9 14:45:38 CST 2007


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.


More information about the Mercurial-devel mailing list