Reusing deleted sub-repo directory in parent repo

[Mike Williams]

On 01/25/11 09:50, Martin Geisler wrote:
> Mike Williams<obsd1 at eandem.co.uk>  writes:
>
>> Here is the fun - the second clone pulls the changes and tries to update.
>>
>> F:\temp\sr>hg pull -R another-clone -u
>> pulling from f:\temp\sr\a
>> searching for changes
>> adding changesets
>> adding manifests
>> adding file changes
>> added 2 changesets with 3 changes to 3 files
>> abort: path 'b/b' is inside repo 'b'
>>
>> The blunderbus solution of blowing away the original sub-repo dir
>> solves the problem but feels wrong.
>>
>> F:\temp\sr>rmdir /s/q another-clone\b
>> F:\temp\sr>hg update -R another-clone
>> 2 files updated, 0 files merged, 0 files removed, 0 files unresolved
>> F:\temp\sr>dir /b another-clone\b
>> b
>>
>> So is this the way things are with folding sub-repos back into the
>> parent? Is there a better way to handle this scenario? Or is this a
>> missing bit in sub-repo support to be filled at some future date?
>
> Hmm... I wont hold my breath for this :) At the moment where you delete
> the .hgsub file, the subrepository become a nested repository, and the
> subsequent write to b/b is then indeed illegal. Mercurial knows knows
> nothing about the former subrepo at that point and wont write into a
> nested repository. That is correct behavior, albeit not the most smooth
> behavior in your case.
>
> You'll see similar things if you update back to a revision where a
> subrepo did not exist: the subrepo will be updated to the null revision
> but is left behind in the working copy. If there is a revision where a
> file is in the way of the subrepo, then you're told:
>
>    % hg update 2
>    abort: Is a directory: /home/mg/tmp/repo/sub
>
> Not as smooth as it could be, but hopefully this is an unusual
> situation.

Thanks for the explanation.  It also answers questions I didn't realise 
I needed to ask which is a bonus.  As you say, this would be an unusual 
situation and can be handled in different ways to how we work currently.

TTFN

-- 
Mike