2

I've had a folder in my repository. Then I have made this folder a subrepository (with the very same files), commited and pushed this change. Now I can't update back through that commit. Here's the message I get:

% hg update --repository <path to repo> --config ui.merge=internal:fail --rev 1159 --clean
abort: path 'subrepo\include\header.h' is inside nested repo 'subrepo'
[command returned code 255 Wed Dec 05 11:57:45 2012]

Where subrepo is the name of that folder where subrepo now resides. Any way to defeat this and update to earlier revision?

Violet Giraffe
  • 32,368
  • 48
  • 194
  • 335
  • I've just had a "play" with mercurial, and it looks like trying to do an update back to before you had the subrepo puts the working directory in an "odd" state. For example, doing an `hg update -C` afterwards tries to restore the files, but doesn't set the working directory state correctly (for me). `hg summary` reports the parents are `-1:000000000000` with no revisions checked out. I'm currently thinking this could be a bug report - will play some more... – icabod Dec 05 '12 at 14:42
  • @icabod: thanks for your time, hoping for further findings. – Violet Giraffe Dec 05 '12 at 14:54

2 Answers2

6

Found a solution: delete the folder in question, then update with the "discard changes" option. Works like charm.

Violet Giraffe
  • 32,368
  • 48
  • 194
  • 335
  • Note, however, that deleting that folder has the potential to lose any changes that were made locally in that subrepo repository. It sounds like that wasn't a problem in your case, but it could cause major problems if someone else did this without realizing the potential for data loss. – davidmc24 Dec 06 '12 at 17:19
  • @davidmc24: Good point, although it should be obvious to any Mercurial user that changes that were not commited AND pushed will be lost. And I don't see any problem commiting and pushing changes to that subrepository regardless of the main repo state. – Violet Giraffe Dec 07 '12 at 07:17
5

After a bit of googling, this looks like it's directly related to Caveat 3, to quote "Update/merge currently can't remove subrepositories entirely as that might lose local-only changes". Also caveat 5 states "Collisions between normal files and subrepos are not handled".

Interestingly, and something I'd not seen before, Subrepositories are considered a "feature of last resort", which is to say something you should try not to use if you can help it.

Probably not the answer you were looking for.

A workaround is to get to your revision by cloning... you can use a new clone based on a revision just before you created the subrepo:

% hg clone --repository <path to repo> new_copy --rev 1159

This will clone everything up to that point, so you will lose any "future history", but will at least be able to get back to an earlier version.

icabod
  • 6,992
  • 25
  • 41