Both Mercurial and BitBucket make one fundamental assumption: 1 repo = 1 project.
If I have a project that has a dependency (a library) which is shared by many projects, this assumption gets in the way. Now it is no longer possible to have a separate BitBucket page for each project while still being able to commit atomic revisions to multiple projects.
If I put all the projects into one repo, they all become one “project” on BitBucket. If I put them in separate repos, it is no longer possible to know which version of the library project was in use at revision X of a dependent project.
How is this situation normally solved on BitBucket, or is there explicitly no support for this common scenario?
Mercurial has the Subrepositories feature which essentially do configuration management of your other repositories. It is extremely easy to setup.
All you have to do is create the .hgsub file like this:
src/app = https://bitbucket.org/<user>/app
src/framework = https://bitbucket.org/<user>/framework
src/library = https://bitbucket.org/<user>/library
One repo per line, path to the left, URL to the right. When you commit, Mercurial will fetch those repositories and prompt you for credentials. After that, and each time you commit, the .hgsubstate file will change automatically depending on the states of your subrepos (revision, branch, or whatever you have selected in each one).
27442cb5903128c6f817e2943030b9297a0d569f src/app
4d11fabc8a6121ceb07e11ddd81fb1e4ad2f5980 src/framework
8d6f570174a535839c189cf84d04f5ae5253a253 src/library
The left side represents the hash, the right side the path to the repo. This file is versioned, but as I mentioned earlier, it gets edited automatically by mercurial.
So if you make a commit on src/app, the hash is going to change. When you are happy with the combination of states in each subrepo you commit the parent repo. *BLAM!*, you have configuration management.
Edit: I just discovered the Hg Guest Repo extension and I think this is just what you need, quoting:
Extension for enterprises needing to handle modules and components
Hg subrepos do not handle the sharing of components well, due to
the recursive merge from the top (super) repo and requirement to
lock at a specific version.
Guestrepo's goal is to overcome these limitations.
The guestrepo extension does not change any existing Mercurial
behavior. It only adds new commands.
2
Both Mercurial and BitBucket make one fundamental assumption: 1 repo = 1 project.
I think you are wrong, at least about the Mercurial part. I have multiple projects inside the same Mercurial repository and it works very well for me (and for many others).
As for BitBucket, it is built around the concept of repositories and it doesn’t go much further than that. It provides a basic wiki and bug tracker, but it is not a project management tool. If you need a separate wiki page per project, you should consider using an external wiki or project management tool.
6
git has submodules
looks like hg has subrepository