5

1

I have a main repository (MainRepo) with all my source code, and a sub repository (SharedLibrary) with some 3'rd party DLL's I want to add to my MainRepo.

For some reason my SharedLibrary folder inside MainRepo is not picking up changes done in the SharedLibrary repository. This is the excact commands I do;

Creating my subrepo:

  • [Creating directory SharedLibrary on my hdd and creating SharedLibrary repo in my kiln website]
  • cd sharedLibrary
  • hg init
  • hg add
  • hg commit
  • hg push "https://myusername@ocea.kilnhg.com/Repo/Repositories/Group/SharedLibrary"

Now I can see my subrepo in kiln website and all looks fine.

Creating my main repository (MainRepo) (with SharedLibrary as a subrepo inside):

  • [Creating directory MainRepo on my hdd and creating MainRepo repo in my kiln website]
  • cd MainRepo
  • hg init
  • hg add
  • hg commit
  • hg push "https://myusername@ocea.kilnhg.com/Repo/Repositories/Group/MainRepo"

Setting up subrepo SharedLibrary in the MainRepo project:

So you should think everything is okay now? So I do a clone of my MainRepo repo and it successfully pulls my MainRepo repo and the subrepo inside. But the problem appears if I check in a new file/or change a file in the subrepo and commits and pushes it to kiln. Then -> on my next clone (or pull) of MainRepo I don’t get the changes at all - it's like it always get's the first version of my SharedLibrary although I can see the changes in my SharedLibrary in kiln website..

flag
do you have a 2nd copy of the shared library inside the main project on kiln? (ocea.kilnhg.com/Repo/Repositories/Group/MainRepo/SharedLibrary) – GalleySlave Jul 16 2010 at 6:38

1 Answer

7

The reason this is happening is that you are committing and pushing from inside the subrepo. In order to keep everything in sync, Mercurial keeps a file in the parent repo called .hgsubstate, which tells Mercurial which version of each repo to get. When you commit and push from inside a subrepo, you aren't telling the main repo to update its version. To make sure that happens properly, always call hg commit from the root of the parent repo so the parent repo's .hgsubstate will get updated too.

I realize this isn't quite ideal -- Mercurial should update the parent repo properly. This is one of the rough edges in the Subrepos feature. Mercurial 1.6 should make this workflow a bit easier.

link|flag
Thanx! But I dont fully understand: C:\Kiln\MainRepo C:\Kiln\SharedLibrary So, I do a change in my C:\Kiln\SharedLibrary.. But "always call hg commit from the root of the parent repo so the parent repo's .hgsubstate will get updated too" is impossible the way I see it. Doing a commit on C:\Kiln\MainRepo will of course not detect the change in C:\Kiln\SharedLibrary... and doing commit on C:\Kiln wont work as this folder itself is not watched.. I'm baffled why this should be so strangely setup... Maybe my subrepository really needs to be nested inside of my MainRepo somehow? – Mcad01 Apr 7 2010 at 8:06
You would go up to C:\Kiln (which is the parent repo) and commit from there (e.g. hg commit MainRepo or hg commit SharedLibrary). – Tyler Hicks-Wright♦ Apr 7 2010 at 14:31
Thats cleared one bit about HG subrepos' for me. Trouble is mods in the subrepos don't show up when you do a commit using the GUI you just get a "S: Subrepos" check box. I know they are working on this feature but until then what is the best way to check what you have changed in the subrepos? Do a dummy commit on the subrepos to double check you've added everything, cancel it then do a commit on the parent repos? Clunky and not "designer safe", roll on version 1.6 – Pete Duncanson Jul 1 2010 at 11:11
You can do this in TortoiseHg V 2.1.2 (& probably earlier) by going to options - recurse into subrepositories. As of now, there is a bug (bitbucket.org/tortoisehg/thg/issue/1130/…) if you add the subrepos via TortoiseHg. It doesn't grok the remote locations. You need to add the to the .hgsub files in the parents of the subs. Tortoise tries to replicate the local file structure. That dun werk. – CADbloke Aug 19 at 9:16
Hi @Tyler, great answer, thanks. Question though, if the the subrepo is a shared library developed by a 3rd party they clearly cannot (and would not) commit and push from within the main repo. How to handle the situation where you want your main repo to use the most current version of a subrepo that you did not update? – mikeschinkel Nov 11 at 6:35

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.