Thoughts on narrow checkouts

Patrick Mézard pmezard at gmail.com
Tue Aug 24 16:01:24 CDT 2010


Le 16/08/10 14:17, Patrick Mézard a écrit :
> 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?

Looking at this, the hard part is to handle the dirstate/manifest coupling. Two examples:
- same matcher objects are often used both for manifest and working directory
- hg log would output store paths in a narrow checkout context, hg manifest too

Another approach would be not to remap the paths at dirstate level but at changelog/manifest/filelog one:
- Rewrite changelog "files" field
- Rewrite manifest entries
- Rewrite filelogs copy records
- Remap access to the store

At this point, the repository should behave correctly, at least in read mode, except for the special files like .hgignore or .hgsub, which required dedicated handling in the first approach too. I suppose the breakage would move to the changegroup (pull/push?) and possibly local clone commands, but that sounds better than dealing with matchers & co.

What do you think?

--
Patrick Mézard


More information about the Mercurial-devel mailing list