I’m currently migrating from CVSNT to Mercurial but am running into problems with what I used to be able to achieve with CVS modules. I have two projects say A and B which both depend on common code in a directory C. If I make a change to code in directory C, I want the changes to be reflected in both projects A and B. (it seems to be the exact reverse of the problem here)
I thought this could be achieved using subrepos but the .hgsubstate in projects A and B keeps a note of the changeset in the sub repo that I list committed against. I.e. I commit a change in C on project A and I have to manually open B to update and commit. (In actual fact there are many more projects that just A and B and yes I know common code should be in a shared library but the PHB insists!)
Is there a way to achieve this? Ideally I’d like it to be transparent to the user how the repos are structured i.e., they can commit a change to C and not have to realise it is a sub repo of their project. (At the moment tortoise Hg uses an ‘S’ to indicate a subrepo is dirty). I guess what I need is a daddy repo and a partial check out but surely there must be a better way? I’m on Windows so symlinks are out.
The fact that you have to manually update (and commit) the subrepository is very much intentional. This misfeature found in CVS and SVN was intentionally left out.
If it would automatically update subrepositories to the latest commit, there is no guarantee that code will remain working. E.g. if you would change the API of C, neither A nor B will work until you change them accordingly. And because you can never push multiple repositories atomically at the same time, there would unavoidably be a window during which A and B do not work. In practice, this window can grow rather large, especially as soon as one of those depending projects receives less development attention. And if project B would be put on hold for a while, the changes to C for project A would break it in no-time.
Worse, updating to an earlier version would not be able to restore the subrepository to the state it was in at the time. So as soon as you would make a backwards incompatible change to the subrepository, older versions would not work anymore! This greatly reduces the usefulness of version control. It would cause problems with branching and e.g. bisecting would not be able to work.
This is why you are required to manually update to the latest version of C, test whether everything still works, and check in that subrepository update. Thereby tightly locking the repository version to the subrepository version. You sacrifice a little bit of convenience, but you gain code stability, and I hope I was able to make clear why this is much better :).
As for transparently committing to a subrepository from within a parent repository, as far as I know it is planned to do this but so far no-one has actually implemented it.