Thoughts on narrow checkouts

[Patrick Mézard]

I am trying to measure the feasability and amount of work to support read-only narrow checkouts as Mercurial subrepositories.

The goal is to have a subrepository type pulling a complete Mercurial repository but checking out only a subtree at a given location. It would work in read-only mode like subversion subrepositories, thus having "pull", "update" and "status" operations should be enough. It would help me solve the problem described here:

    http://www.selenic.com/pipermail/mercurial/2010-August/034261.html


My current approach would be to:
1- Isolate the functions accessing the working directory items in one place, instead of having them scattered between localrepo and dirstate.
2- Override them in the narrow checkout case so that:
  a- The input paths are rewritten according to the narrow checkout definition, returning None if the entry was excluded
  b- If the rewritten path exists, operate on the rewritten path
  c- Else use the parent revision to fake read operations, and turn write operations into no-ops
3- Add a new subrepo type like [hgreadonly] where the .hgsubstate would store the revisions as nodeid at subpath. A narrow checkout command may be useful too, so the "checkout then register in .hgsub" workflow would still be usable (instead of editing .hgsubstate directly).

Difficulties:
- Preserve dirstate performance while isolating the FS api, at least in the normal case. Having a slower dirstate for narrow checkouts as subrepos may not be a big deal.
- Handle subrepository .hgignore and .hgsub cleanly in the narrow checkout context
- inotify

Any opinion about this?



Related discussions about narrow clones, not narrow checkouts:

    http://mercurial.selenic.com/wiki/PartialClone

--
Patrick Mézard