Question

I have been trying to follow the instructions in the answer to this question, using kiln.

i’d like to be able to arrange things as follows:

• /somepath/thirdparty maps to a kiln repository “thirdparty” and contains assorted code
• /somepath/common maps to a kiln repository “common” and contains shared code i have written

and

• /somepath/project1 maps to kiln repository “project1”
• /somepath/project1/thirdparty maps to branch of thirdparty above
• /somepath/project1/common maps to branch of common above

and

• /somepath/project2 maps to kiln repository “project1”
• /somepath/project2/thirdparty maps to another branch of thirdparty above
• /somepath/project2/common maps to another branch of common above

I found that when I created the .hgsub file as instructed and added/pushed it to Kiln, I could no longer view the Kiln files in the Kiln web file viewer — it displayed an obscure message about the Kiln “overheating” 🙂 Additionally, whilst it did automatically create the subfolders in the correct place, they were not populated with files, (possibly because the pull failed).

Anybody tried anything like this before, using Kiln?

As I intend to develop a number of apps using the common code (and potentially eventually release the library as open source), I would like to have it managed in discrete repositories. As some of the projects are for end clients however, I need to be able to give them a single repository that includes things as described above.

Answer 1

Kiln does currently not support subrepos that use nested URLs on the server. This means that you cannot have both the following URLs working:

http://server/kiln/somepath/project1
http://server/kiln/somepath/project1/thirdparty

So you should setup Kiln so that you have four repositories on the server:

http://server/kiln/somepath/project1
http://server/kiln/somepath/project2
http://server/kiln/somepath/thirdparty
http://server/kiln/somepath/common

That’s easy — just four normal repositories. Then clone “project” and create the .hgsub file with:

thirdparty = http://server/kiln/somepath/thirdparty
common = http://server/kiln/somepath/common

When you push that back to Kiln, it will notice and display links for the subrepositories. However, the subrepositories wont end up being nested on the server. So there wont be any project1/thirdparty path on the server.

It’s also far from clear that you would want that. When you have several projects that collaborate and use some common code base, then you want “project1” and “project2” to get each other’s changes to this common code base. So it very useful that the common subrepo in both projects push and pull from http://server/kiln/somepath/common.

In Mercurial, we normally recommend that you use paths of the form common = common in the .hgsub file. This means that the server must support nested repositories. When Kiln doesn’t support nested repos, you can use full paths instead.

When you initially setup the subrepositories, then remember that you need to update them manually. So with the above URLs, you would setup “project1” by running:

$ hg clone http://server/kiln/somepath/project1
$ echo "common =     http://server/kiln/somepath/common" > .hgsub
$ echo "thirdparty = http://server/kiln/somepath/thirdparty" > .hgsub
$ hg commit -m "Created subrepos"

This creates initial empty subrepositories. They are empty because you haven’t told Mercurial which changeset you need in them. This is tracked in .hgsubstate where you’ll find:

0000000000000000000000000000000000000000 common
0000000000000000000000000000000000000000 thirdparty

To populate the subrepositories you do

$ cd common
$ hg pull --update
$ cd ../thirdparty
$ hg pull --update
$ cd ..
$ hg commit -m "Updated subrepos"

This updates the 000... lines in .hgsubstate with the current tip changeset IDs for the two subrepos. Future clones of “project1” will notice the .hgsubstate file and make sure to update the subrepos to the revision mentioned there.