Mercurial hg Subrepository issue - "abort: unknown revision'

Question

Note: I asked this yesterday over at kiln.stackexchange.com, but haven't gotten an answer, and it's holding up my work. So I figured I'd give it a shot here.

My main mercurial repository has a bunch of subrepositories in it. During initial setup, I made a mistake in my .hgsub. Namely, I pointed two subrepositories to the same directory.

What I should have had:

sites/1=sites/1
sites/2=sites/2
sites/3=sites/3

What I actually had:

sites/1=sites/1
sites/2=sites/2
sites/2=sites/3

Stupid copy/paste error. I committed the incorrect .hgsub, not realizing my error. A few revisions later, while adding a some new subrespositories to .hgsub, I noticed the mistake and fixed it inside .hgsub. I committed and kept rolling along. I've committed a reasonable amount of work that I'd prefer not to redo since I 'fixed' the mistake in .hgsub.

Now we come to the actual problem: I've made some changes inside the subrepository sites/3, and when I try to commit the main repository, I get the following error:

abort: unknown revision 'LongGUIDLookingString'

I found this discussion, which seems to address the same problem I'm having, but I can't quite work out how bos fixed it. What do I need to do in order to fix this?

Relevant section of .hgsubstate:

7d1e430ac5f12e00cb5bebcdf693e72db2c45732 sites/1
6eea936a5b7cfff6169f59d0dc1c8c4eb5f8412d sites/2
e2b83b301997de8add1b659d82a7ab8201bda653 sites/3

Figwort

Is there a + at the end of the string? – Artimas

No plus. Here's the actual string: 'e2b83b301997de8add1b659d82a7ab8201bda653'. – Figwort

@tonfa: what if it does have the + at the end? (it does for me but being ungooglable I don't know where to go from here). – Lannie

@romkyns the + at the end means the subrepo is dirty (aka modified), I don't think such hashes are supposed to end up in .hgsubstate – Artimas

Answer 1

I'd guess the .hgsubstate file now contains a hashid (which is what your LongGUIDLookingString is) from repo3 in the repo2 entry.

Try editing .hgsubstate to point to a correct/present hashid for each repo.

If that doesn't work, please paste i your .hgsubstate file so we can see how it can be tweaked.

Ratal

Are you talking about the changeset hashid? The changeset hash IDs of the subrepos don't look anything like the hashes in .hgsubstate. Or is there another hashid associated with the sites/3 subrepository (other than inside .hgsubstate)? I've added the relevant section of .hgsubstate to the original question. – Figwort

Ok, I see now that mercurial usually shows a shortened version of each changeset id. hg --debug tags gets the longer version. I executed that on sites/3, pasted the tip changeset id into .hgsubstate on the sites/3 line, and I'm now able to commit again. Looks to be cleaned up now. Thanks for the help! – Figwort

No prob. I should've mentioned the long-form (complete) hashids. You can get them as {node} in the template language: hg log --template '{node}' with '{node|short}' getting you the ones you're used to seeing. – Ratal

Answer 2

For those who struggle committing changes to .hgsubstate, it appears that:

• hg commit -i is not working while
• hg commit -m does.

Valued