1

I have a Windows file structure like so:

Stable
    ProjectA
    SharedLibrary

Stable contains the main repo. ProjectA and SharedLibrary are subrepos of Stable. The .hgsub file contains:

ProjectA = ProjectA
SharedLibrary = SharedLibrary

Everything seems to work correctly for the most part. The main repo will recognize the subrepos, and I can do things like hg status -S on the main repo and it will recurse through the subrepos. commit also seems to work correctly.

When I try to clone from Stable (main repo), it fails when attempting to clone the ProjectA subrepo with the following message:

unknown revision 'a855f4fe17c393d5863409f1443fc93b36787fa9'
[command returned code 255 Mon Mar 12 09:25:47 2012]

However, I have verified that the revision is correct and present in the ProjectA subrepo. I can clone each subrepo without any problems.

So far I have tried: 1) Deleting each repository and starting over. 2) Re-installing TortoiseHg/Mercurial. 3) Making sure the revision listed in .hgsubstate is correct and present in each subrepo.

Any way to fix this?

EDIT: When the clone of the Stable (main) repo fails, it leaves the target directory with a clone of Stable without any subrepos. I can go to the cloned Stable, do an hg update tip, and it will successfully clone the ProjectA subrepo but fail to clone SharedLibrary with the same 'unknown revision' error. I can then run hg update tip again, and it will successfully clone the SharedLibrary subrepo. At that point everything is correct as it would be if the clone had worked correctly in the first place.

EDIT 2: Contents of .hgsubstate:

a855f4fe17c393d5863409f1443fc93b36787fa9 ProjectAd72ef29a5656e5413322c1d20d5830448d558605 SharedLibrary

There is no space between ProjectA and the changeset id for SharedLibrary, but I guess that is just the way Mercurial does it. Both changesets in .hgsubstate are present in the respsective subrepo.

EDIT 3: hg log --debug -r tip from ProjectA subrepo. showing correct changeset is present

Z:\Programming\KSuite\Stable\Client\KClient>hg log --debug -r tip
changeset:   4:a855f4fe17c393d5863409f1443fc93b36787fa9
tag:         tip
parent:      3:eb01e88027c893267422fcb67f035ba31d8cdbdc
parent:      2:5b5ffd7f96915ca792507820ccfbee35707148d0
manifest:    4:e90960833c0708ec7f99ccded11c46ca45b46542
user:        Casey ******** <*redacted*@.com>
date:        Fri Mar 09 18:22:50 2012 -0500
files:       .hgignore
files-:      KClient.suo
extra:       branch=default
description:
Merging changes in Stable to Dev.
krtek
  • 26,334
  • 5
  • 56
  • 84
Casey Wilkins
  • 2,555
  • 2
  • 23
  • 31
  • Check hgsubstate and mentioned in it changeset-id ? – Lazy Badger Mar 12 '12 at 14:17
  • @ Lazy Badger, I'll update with contents of hgsubstate. – Casey Wilkins Mar 12 '12 at 14:23
  • I see `a855f4fe17c393d5863409f1443fc93b36787fa9`, mentioned in error also. Do you have this revision in ProjectA? `hg log` it – Lazy Badger Mar 12 '12 at 15:07
  • @LazyBadger, Yes, that revision is in ProjectA. I'm working on another issue I'm having that may fix this one, so hold that thought and I'll report back. – Casey Wilkins Mar 12 '12 at 15:20
  • @LazyBadger, updated the question with output of hg log --debug -r tip from the ProjectA subrepo. Still having same problem after fixing the other issue. – Casey Wilkins Mar 12 '12 at 16:03
  • Just for testing: can you up to any other revision and return back? I haven't another idea except to change binding to another revision of ProjectA or summon @MartinGeisler here – Lazy Badger Mar 12 '12 at 17:03
  • You should verify the contents of the .hgsubstate file, you might have opened/verified it with a text editor that does not know how to handle linefeeds correctly from other platforms. The correct way this file is supposed to be formatted is one line per sub-repo, and a space after the hash. In other words, there should've been a linefeed after ProjectA there. Please verify that this linefeed is present, otherwise I would suggest making a copy of the whole folder, and manually editing it in, to see if that helps. – Lasse V. Karlsen Mar 12 '12 at 20:20
  • @LazyBadger, there are only two commits in the real repo so I can't up to another revision, but I'll copy it, make another commit, and try to up to it. If that works and it just looks like it affects this rev for some reason, I can live with that. – Casey Wilkins Mar 13 '12 at 15:04
  • @LasseV.Karlsen, I had originally opened it in Notepad (not thinking) which doesn't honor the linefeed. Opening it in Wordpad shows that the file is formatted as you describe, one repo per line, but it still fails to clone. – Casey Wilkins Mar 13 '12 at 15:05
  • @LazyBadger, I copied the repo, commited a change, then cloned the repo and it worked this time. Evidently there is just something wrong with the specific changeset I'm on. I guess I can live with that, so consider it problem solved. Glad to accept an answer from you if you care to post one. – Casey Wilkins Mar 13 '12 at 15:10

0 Answers0