What is the correct way to handle nested Hg repositories with Mercurial/TortoiseHg?

Question

I'm struggling on how to correctly track nested repositories using TortoiseHg.

I have a main repository that tracks my whole project. This project contains several little plugins that are stored inside a plugins/ subdirectory.

I would love to track each plugin independently (committing and pushing to BitBucket for each one of them) while still being able to make a "whole" commit of my project, including the changes made to the plugins and pushing it to an other location (not BitBucket).

What I've done so far is creating a new repo for each of my plugins. I can commit and push them to BitBucket easily. But when I went to commit my "main" repository, TortoiseHg displays an error message saying that abort: path 'mainrepo\\plugins\\plugin1\\plugin1.php' is inside repo 'mainrepo\\plugins\\plugin1'.

I can see that I'm doing something wrong, but I can't tell what.

I'm using a nightly of both Mercurial and TortoiseHg (ToirtoiseHg version 0.9.3+237-ea50f793bbe4 and Mercurial-1.4.3+225-70dea42c9406) on WinXP. I read that subrepos handling was added to this TortoiseHg build, but, well, I'm not even sure subrepos is the feature I'm supposed to use here.

Update
I've made some progress, but still can't get it to work the way I'd like.
Here is my structure :

-- .hg
-- core
-- app
    -- file.php
    -- file.css
    -- plugins
        -- plugin1
            -- file1.php
        -- plugin2
            -- file2.php

I went to app/plugins, and cloned a plugin (named plugin3) from BitBucket here. I then created a .hgsub file at the root and added app/plugins/plugin3 = app/plugins/plugin3 to it. I was then able to commit my whole directory.

But then I tried to grab the latest version of plugin1 from BitBucket, so I went to app/plugins, deleted the plugin1/ folder and cloned the plugin1 from BitBucket. I then added app/plugins/plugin1 = app/plugins/plugin1 to .hgsub but when I tried to commit it I was greeted with abort: path 'app/plugins/plugin1/file1.php' is inside repo 'app\\plugins\\plugin1'

The problem seems to fire when my subrepo holds the same name as a directory already tracked by Hg in the plugins/ directory.

What am I doing wrong ? Should I add/edit something special in the .hg of my plugins ?

Update
I've finally managed to get it to work the way I want.
I had to "manually" tell Mercurial to remove the plugins/plugin1, plugins/plugin2 directories, commit the change, then clone back the plugin1 and plugin2 from BitBucket, add app/plugins/plugin1 = app/plugins/plugin1 to .hgsub and commit all. It worked.
The important step was committing after having deleted the plugin1/plugin2 folders.

Answer 1

I've finally managed to make it work the way I'd love. I'm using TortoiseHg on winXP, so I won't be able to tell you what hg calls were internally made, but I don't think anything fancy is used here.

I started with an existing repo, inside which I had a plugins/ directory filled with plugin1/, plugin/2 directories (not repositories, just simple directories). I also had those plugins online, hosted on BitBucket.

• I first went to my plugins/ directory, right click on plugin1/, TortoiseHg => Remove Files.
• I get back to the root of my repo, right click and Hg Commit
• Then I went back to my plugins/ directory, right click, TortoiseHg => Clone..., I selected the http address of the plugin on bit bucket (http://bitbucket.org/username/plugin1/ and clicked Done
• The back again to the root of the main repo. I created (or edited if the file already existed) a .hgsub file and add the plugins/plugin1 = plugins/plugin1 line inside it.
• I was then able to either commit the main root repo, or the plugin1 repo independently

Note that the extra remove and commit steps are only required if the newly cloned repo has the same name of an already tracked directory.

Answer 2

You should try using:

• The Forest extension or
• (better choice, because officially in the Hg): the Subrepo feature

Subrepositories is a feature that allows you to treat a collection of repositories as a group.
This will allow you to clone, commit to, push, and pull projects and their associated libraries as a group.