I used the have the following line in my .hgsub
for years:
setup/help = https://my.repo.com/manuals
It would place the repository named "manuals" into a folder help
inside another folder setup
. So my parent repository structure looks like this:
.hg
setup
|__help
| |__.hg
|
.hgsub
This was no problem until I updated to Mercurial 4.9 today, it now says: "subrepo path contains illegal component: setup/help", and I can't even commit to the main repo. Does Mercurial forbid this now? Is there a valid .hgsub
syntax to make this work? I don't want to move help
to be a direct child of the main project folder. My previous Mercurial version was 4.5, it's not like I was using ancient tools...
Error traceback as per the request:
Traceback (most recent call last):
File "mercurial\scmutil.pyo", line 165, in callcatch
File "mercurial\dispatch.pyo", line 367, in _runcatchfunc
File "mercurial\dispatch.pyo", line 1021, in _dispatch
File "mercurial\dispatch.pyo", line 756, in runcommand
File "mercurial\dispatch.pyo", line 1030, in _runcommand
File "mercurial\dispatch.pyo", line 1018, in <lambda>
File "mercurial\util.pyo", line 1670, in check
File "mercurial\commands.pyo", line 4621, in push
File "mercurial\context.pyo", line 277, in sub
File "mercurial\subrepo.pyo", line 164, in subrepo
File "mercurial\subrepo.pyo", line 414, in __init__
Abort: subrepo path contains illegal component: setup/help
abort: subrepo path contains illegal component: setup/help
How confident are you with a Python debugger? You can launch the command with the
--debugger
this time.You might see an output like this:
Enter
c
andenter
until you see the same traceback as the one you pasted.When you are at the right traceback, you can print the local variables using
pp root
,pp util.expandpath(root)
andos.path.realpath(util.expandpath(root))
. We should be able to get to the root of the issue with the values of those variables.To exit the debugger, enter
q
andenter
.I had the same error, so I cloned the mercurial repository...
The error was introduced in tagged version 4.9, subrepo.py.
It was corrected about a month later, revision 41583 (87a6e3c953e045d92147925fc71aad7c327fdbfd). I tested it on the actual default branch, works again!
So, no need for a bug entry, we just have to wait for the next release.