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