Thoughts on narrow checkouts

Patrick Mézard pmezard at gmail.com
Wed Aug 18 03:08:56 CDT 2010


Le 18/08/10 09:42, Didly Bom a écrit :
> On Wed, Aug 18, 2010 at 2:49 AM, Matt Mackall <mpm at selenic.com <mailto:mpm at selenic.com>> wrote:
> 
>     On Mon, 2010-08-16 at 14:30 +0200, Martin Geisler wrote:
>     > Patrick Mézard <pmezard at gmail.com <mailto:pmezard at gmail.com>> writes:
>     >
>     > Hi Patrick,
>     >
>     > > I am trying to measure the feasability and amount of work to support
>     > > read-only narrow checkouts as Mercurial subrepositories.
>     >
>     > I think this sounds like an interesting and useful feature.
> 
>     Agreed. Though if we're going to be read-only, we might as well think
>     ahead to narrow pulls as well.
> 
> 
> I also think that this could be a very useful feature!
> 
> Is there a technical reason (other than the additional development effort) to make these narrow checkouts read only? Or could this be a first step towards full narrow checkout support?

Actually it depends whether we want narrow checkouts or narrow clones. If the approach I described is valid, read-only narrow checkouts could probably be extended to writable ones: once your are able to trick the dirstate/fs-operations to think they operate on the whole checkout instead of a subset of it, all operations should work accordingly, except for stuff depending and repo wide paths like .hgignore, matcher objects and the likes. Read-only narrow clones are probably harder to implement than read-only checkouts, and much harder to make writable, but I could be wrong.

So my current plan was to go for narrow checkouts because the read-only case seems doable, because I don't have real issues with cloning full repositories even if I checkout only part of them and because I believe they can be made writable later with the same approach.

--
Patrick Mézard


More information about the Mercurial-devel mailing list