3

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 parent repo?

Joel B Fant
  • 24,406
  • 4
  • 66
  • 67
jpshook
  • 4,834
  • 6
  • 36
  • 45

3 Answers3

3

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.

jpshook
  • 4,834
  • 6
  • 36
  • 45
2

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.

Chris
  • 21
  • 3
  • thanks for your answer. Just to clarify, parent is the repo that holds the subrepo, not the source for the subrepo? Also, in the .hgsub, should it map to the remote subrepo or the remote subrepo source? – jpshook Sep 01 '11 at 16:06
  • 1
    Also, on the wiki for subrepos it states "When we commit, Mercurial will attempt to create a consistent snapshot of the state of the entire project and its subrepos. It does this by first attempting to commit in all modified subrepos and then recording the state of all subrepos. (Commit includes subrepositories by default because it is intended to create an atomic snapshot of the tree that you presumably built and tested before committing.) " – jpshook Sep 01 '11 at 17:23
1

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.

Lasse V. Karlsen
  • 380,855
  • 102
  • 628
  • 825
  • 2
    The main subrepository wiki clearly states that commits are recursive. What I have discovered though is that hg add is not. So new files added will not found by the main repo. Next issue, is I know I can do a push and it will push back to the subrepo on the server, but how can I also have that push back to the original source repo that the subrepo was cloned from without logging into the server. I need a easy workflow for ensuring all my subrepos get the changes made in one in the others. – jpshook Sep 01 '11 at 21:42