[PATCH 1 of 2 RFC] subrepo: create subrepo cache and create working dir subrepos as shared repos

[Angel Ezquerra]

On Mon, Jan 13, 2014 at 12:41 PM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2014-01-13 at 14:38 -0600, Matt Mackall wrote:
>> On Fri, 2013-11-15 at 21:15 +0100, Angel Ezquerra wrote:
>> > - This change is backwards compatible.
>>
>> What if an old client tries to work with a repository checked out by a
>> newer hg?
>>
>> What if a new client tries to work with a repository checked out by an
>> older hg?
>>
>> I don't see any form of fallback handling, so I'm not sure how either of
>> these could work.
>
> Sorry, I see how this works now. Very clever.

Thanks :-)

> This does, however, leave us with a nasty cache management problem.

I'm not quite sure what exactly you mean by a nasty cache management
problem. Could you elaborate?

In any case I don't think these changes make things any worse than
they are now. We already have a subrepository cache, the working
directory itself! What this patch series does is move that existing
implicit cache into the .hg folder, which fixes (or makes it possible
to fix) a number of the well known issues with the current subrepo
behavior:

1. You cannot remove subrepos from your working directory unless you
are willing to reclone them if you update to a revision that needs
them. Even if you are willing to do that then you cannot serve your
repo to other users due to the missing subrepos.

2. Problem #1 makes it very tricky to convert an existing regular
folder into a subrepo or viceversa. If you do there are problems when
you try to update back and forth between the corresponding parent repo
revisions.

3. Moving or copying a subrepo requires having two full copies of the
subrepo. With a proper cache we could potentially avoid that. Also
both copies must be on the working directory, including one at the
original location of the subrepo that you moved, which is very ugly.

4. When you use subrepos the .hg folder does not contain the whole
history of your repository (this feels to me as a deviation from the
basic mercurial design).

So I think this is a net win...

Angel