Can I commit changes to multiple mercurial subrepos to a new named branch?

I have a mercurial repository with multiple sub repositories inside it. The repository has a visual studio solution containing projects in the repository and the subrepository.

Suppose I want to implement a new feature that will require changes to the main project 开发者_Python百科in the repository and changes to one of it's dependency projects in the solution (let's say, adding a new shared interface in the dependency, and an implementation of the interface in the main project).

I then want to commit the changes, but to a new named branch as it is unfinished and will be merged in later. Using tortoiseHg I commit the changes in the repository, specifying a new branch to create. The commit in turn commits the changes of the sub repo, but in my tests it doesn't create a new branch in it's repository, but just adds the changeset to the current branch.

I can perform the commit to the sub repo explicitly and specify the branch name at that time but I was hoping for a way to commit the whole change set across repositories to new branches in each repository on one go so my workflow is cleaner. Is this possible?

---

First commit the sub-repo and create a named branch there.

Afterwards the main commit should continue to commit to that sub-repo in the same branch as before.

First you should think of the two repositories as separate, completely separate. In other words, you do something in one repository and commit that. Then you do something in the other repository, and commit that.

The relationship the two repositories have is that the main repository stores a file, the .hgsubstate file, which contains the hash of the parent of the working folder of each sub-repository.

In other words, the sub-repository has no knowledge in itself that it is being part of a bigger picture. However, the main repository knows the current checked out revision in that sub-repository. This knowledge is committed into the repository as part of normal commits.

This means that if you do something in the sub-repository, commit that, the sub-repository is now at a new revision. When you later commit in the main repository, the hash of that new revision in the sub-repository is updated into the .hgsubstate file, and then committed.

The purpose behind this is of course that if you update to an older revision in the main repository, an old copy of the .hgsubstate file is brought into the working folder as well, and then the sub-repository is then updated to that revision, which has the effect of turning back the clock to how the sub-repository looked like when those revisions where in play.

Additionally, commands on the main repository sometimes work on the sub-repositories as well. If you push in the main repository, the sub-repositories are pushed as well, to ensure that others who clone your main repository can also safely rely on being able to clone the appropriate content for the sub-repository.

So to answer your question in the comments.

If you create a branch in the sub-repository, named or otherwise, you will keep committing new changesets down that branch. At some point you need to merge, and you need to merge in the sub-repository as well as in the main repository.

First you would merge in the sub-repository. This ends with a commit, which means the sub-repository is now at the changeset that committed the merge. Then you merge in the main repository and commit, which stores that knowledge, which changeset in the sub-repository that is in use right now.

So yes, you need to merge in both as well, at a later point.