Reusing deleted sub-repo directory in parent repo

[Martin Geisler]

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.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/en/services/mercurial/blog/