Mercurial Subrepos, how to control which changeset I want to use for a subrepo?

Question

I am reading up on subrepos, and have been running some tests locally, seems to work OK so far, but I have one question.

How do I specify/control which changeset I want to use for a particular subrepo?

For instance, let's say I have the following two projects:

class library                    application
o    fourth commit               o   second commit, added a feature
|                                |
o    third commit                o   initial commit
| 
| o  second commit
|/
o    initial commit

Now, I want the class library as a subrepo of my application, but due to the immaturity of the longest branch (the one ending up as fourth commit), I want to temporarily use the "second commit" tip.

How do I go about configuring that, assuming it is even possible?

Here's a batch file that sets up the above two repos + adds the library as a subrepo.

If you run the batch file, it will output:

[C:\Temp] :test
...
v4

As you can see from that last line there, it verifies the contents of the file in the class library, which is "v4" from the fourth commit. I'd like it to be "v2", and persist as "v2" until I'm ready to pull down a newer version from the class library repository.

Can anyone tell me if it is possible to do what I want, and if so, what I need to do in order to lock my subrepo to the right changeset?

Batch-file:

@echo off
if exist app rd /s /q app
if exist lib rd /s /q lib
if exist app-clone rd /s /q app-clone


rem == app ==
hg init app
cd app
echo program>main.txt
hg add main.txt
hg commit -m "initial commit"
echo program+feature1>main.txt
hg commit -m "second commit, added a feature"
cd ..

rem == lib ==
hg init lib
cd lib
echo v1>lib.txt
hg add lib.txt
hg commit -m "initial commit"
echo v2>lib.txt
hg commit -m "second commit"
hg update 0
echo v3>lib.txt
hg commit -m "third commit"
echo v4>lib.txt
hg commit -m "fourth commit"
cd ..

rem == subrepos ==
cd app
hg clone ..\lib lib
echo lib = ..\lib >.hgsub
hg add .hgsub
hg commit -m "added subrepo"
cd ..

rem == clone ==
hg clone app app-clone

type app-clone\lib\lib.txt

---

Edit: Ok, I got my answer, thanks @VonC, I added the following section to my batch-file, above the rem == clone == line, and re-executed it, and now it locks the subrepo to the correct changeset.

rem == lock ==
cd app\lib
hg update 1
cd ..
hg commit -m "lock to second commit"
cd ..

Answer 1

Not tested, but you should be able to go within your subrepo, update its content to the right commit (hg update), go back up one level (in the main project) and commit.
That should update the .hgsubstate with the right commit.

(extreme workaround, update that .hgsubstate yourself, but that is not recommended.)

The all idea of hg subrepos (or Git submodules) is to allow a dependency management by referencing a fixed id for a given sub-repo. If no id is given when creating the subrepo, then the latest id is selected (v4 in your case), but you can checkout whatever id you need.

Actually, this thread even complains that:

Right now, commit recursively tries to commit subrepositories before committing the current repository.

That allows you to:

• record some changes in the sub-repo.
• update the .hgsubstate of the main project with the new state (id) of the subrepo.

Answer 2

Your sub-repo revision won't be advanced without you explicitly choosing to do so, so all you have to do is set it up as you'd like initially. When initially creating the sub repo, just use a '-r' argument to clone only up to the changeset you'd like:

rem == subrepos ==
cd app
hg clone -r CHANGESETYOUWANT ..\lib lib
echo lib = ..\lib >.hgsub
hg add .hgsub
hg commit -m "added subrepo"
cd ..

note the modification on line three.