Mercurial Subrepositories - Do you have to commit in the subrepository and then commit on the main repository?

Using TortoiseHg 2.1.3 and Hg 1.9.2. No matter what I do, the parent repo is not seeing new files created in the subrepo unless I first commit them in the subrepo. I thought all commits and pushes were only supposed to be done on the开发者_JAVA技巧 parent repo?

In further testing, I discovered that changes to files in the subrepo were committed, but new files were not. This is due to the fact that commits are subrepo aware and recursive by default, but hg add operations are not. You must add the --subrepo hook on to the hg add for it to consider the subrepo.

Nope. Mercurial will insist on changes being committed on the subrepo before the parent will pull them. Until the subrepo has committed changes, there is no existing changeset to be pushed to the parent.

You will also likely be asked to pull down any new changesets integrated since your subrepo was created and merge them in with your changes before Mercurial will allow the new changeset to be pushed up.

Here is what is happening.

Let's assume that you only change a file in the subrepo. This will help with the explanation.

The only relationship the parent repository and the subrepo has, is that the parent repository knows it has a folder with a subrepo in it, and it knows the changeset that subrepo is supposed to be. This information is tracked, which means that different versions of the parent repository might have different subrepos, or reference different changesets in the subrepo.

Since this information is stored in normal files, all normal rules regarding detecting changes and such apply. If the file contents are the same as the parent changeset of the working folder, there are no changes to those files.

This mechanism allows you to update back to an old changeset in the parent repository, and have it recursively update (and add or remove) subrepos to their respective changesets, as they were at the time the changeset in the parent repository was committed. This is done simply by looking at the files that track this information and recursively applying this knowledge to subrepos.

So, you changed a file in the subrepo, and you ask the parent repository to commit. However, you have not changed the list of subrepos, nor have you changed which changeset the subrepo is currently referencing. The changes in the working folder of the subrepo is not considered.

As such, the parent repository has no changes, and thus you cannot commit.

If, on the other hand, you commit in the subrepo first, then that repository is now referencing a new changeset as the parent of the working folder.

And then, if you commit in the parent repository, the subrepo tracking code will see this new changeset in the subrepo, update the files that track this information in the parent repository, and then you have changes to commit.