Cannot update to old revisions after converting a folder into a subrepo

[Didly]

On Mon, May 23, 2011 at 8:53 AM, Martin Geisler <mg at aragost.com> wrote:
> Didly <didlybom at gmail.com> writes:
>
>> We have recently discovered that after converting a folder into a
>> subrepo (with the same name) you are no longer able to update back to
>> a revision before the subrepo was created (or at least it is not
>> easy).
>
> This is caveat nr 3 here:
>
>  http://mercurial.selenic.com/wiki/Subrepository#Caveats
>
> While this problem has been known for a long time, it has not bothered
> any of us core developers enough to make us come up with and implement a
> solution.

That is why I wish the core devs had a better excuse to use subrepos
on their daily work. But we've already discussed that at lengh in the
past... :-)

At least now I know that this is a known problem.

>> I believe that this is quite an easy problem to hit. The only reason
>> we had not faced it ourselves so far is that when we converted some
>> folders to subrepos we took the chance to reorganize our code,
>> renaming some of the folders that were later converted into subrepos.
>>
>> From a regular (not too savvy) user point of view, this leaves the
>> repo on a "broken" state, since it is no longer possible to access
>> some repo revisions using just hg commands.
>>
>> I think that a (possibly silly) solution to this problem would be that
>> mercurial "stored" a "copy" of the subrepo in its ".hg" folder (as it
>> does for any regular file). It could do so when updating to a version
>> of the repo that did not include the subrepo. Then, it would be safe
>> for mercurial to delete the subrepo upon update, making this issue go
>> away.
>
> Instead of a copy, I think Mercurial could move the subrepo to a place
> inside the .hg folder when you do an update to a revision without the
> subrepo. Moving is much faster than copying and would keep state such as
> the .hg/hgrc file in the subrepo and maybe even the working copy.

Sure, that is what I meant! I should have said "move", since the whole
point was for the subrepo to no longer be there, in order to let
mercurial create the files that were previously stored in the folder
with the same name as the subrepo.

> When you update back to a revision where the subrepo is needed, then
> Mercurial should first look in its "subrepo cache" to see if there is a
> matching subrepo, move it back in place and do any further pulls needed
> to bring the subrepo up to the revision the .hgsubstate file asks for.

Actually, maybe it could even try to create a hardlink to the
subrepo's "stored".hg file on filesystems that support it?

> This is somewhat magical and would kind of turn the .hgsub file into a
> file with hints for where to get a subrepo. It reminds me a little of
> how I recently tried to make 'hg clone a b' use a/sub as a source of
> changesets when creating b/sub -- since the changesets for sub were
> already there on disk and so didn't need to be downloaded again.

I'd rather have "magical" than "non working" :-P

I don't even think the behavior would be that magical. To me it would
not be that different to what mercurial currently does for regular
files. That is, when they are not needed for a given revision they are
removed from the working directory but they are still "stored" (as
deltas) on the .hg folder...

I also see a certain kind of parallelism to the idea that you mention.
I think it makes sense to avoid hitting the network whenever possible.

Thanks!

Angel