Is the subprepos feature in Mercurial 1.4.x ready for production use?

Question

I\'d like to evaluate Mercurial for my working projects. But most of my projects very heavily rely on the presence of svn:externals-like support. I\'ve searched over StackOv

Answer 1

I've had good luck with the feature in my (light) usage of it so far. It's come in handy in two places:

1. Backing up a tree of unrelated repositories with a single hg pull command.
2. Tying a project together with specific versions of its dependencies, so that a single hg clone gets buildable source code. This is closer to the typical svn:externals usage.

Here are a couple of the limitations I've seen with it so far:

1. In case #1 above, you have to commit all subrepos at once. This is only occasionally annoying, as Mercurial (like any DVCS) encourages frequent commits—so most repos aren't left sitting around in an incomplete state to begin with.
2. Only the most basic Mercurial commands are subrepo-aware: clone, push / pull, update / commit, and perhaps a couple of others.
3. Extension authors are going to need time to test their extensions against repositories with subrepos.

When the Mercurial team describes the feature as "experimental," they don't mean that it's suddenly going to decide to erase all your data. They just mean that they haven't coded around all the edge cases like name conflicts (e.g., one developer adds a subrepo called README, while another developer adds a text file called README).