Thoughts on narrow checkouts

[Patrick Mézard]

Le 18/08/10 23:58, Matt Mackall a écrit :
> On Wed, 2010-08-18 at 10:08 +0200, Patrick Mézard wrote:
>> 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.
> 
> It's going to be very difficult to deal with merges that affect files
> outside the scope of the merge. Even for files without conflicts, we use
> the working directory to record what file revision the merge algorithm
> chose so that commit can do the right thing. And remember: merge here
> can mean even a normal update.
> 
> Read-only obviously side-steps all these sorts of problems.

Right, I overlooked the merge part. Re-reading http://mercurial.selenic.com/wiki/PartialClone , the plan looks like:

"""
The simplest approach is probably "allow cloning of subdirectories". Here's how that would work:

    1- add a file called "subdir" to .hg/store containing the subdirectory we're cloning
    2- do a clone as usual, but don't write out revlogs that aren't in subdir
    3- adjust the functions dealing with paths (localrepo.wjoin, etc.) appropriately
    4- teach various things (checkout, status, etc.) to skip files outside the subdirectory
    5- teach merge not allow merging when files outside the subdirectory conflict
"""

Excluding [5], it seems that [3] is my plan for narrow checkouts and in my case [4] is automatic. I suppose that [4] is necessary in the narrow clone case to deal with missing manifest entries, copy sources, etc...

So, narrow checkout looks like a necessary step for narrow clone. Am I right?

--
Patrick Mézard