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 StackOverflow and googled for corresponding support in Mercurial. All I found is subrepo feature added in Mercurial 1.3, but the page for this feature said:

subrepos are an experimental feature for Mercurial 1.3. So don't do this on mission critical repositories!

I don't want to use something unstable.

Can anybody shed some light on the real status of this feature, and the plans of polishing/finishing it and when it will be called "stable" and ready for mission critical repositories?

Chill

I've updated the wiki to be more clear about the status, I hope that helps. – Accordingly

Answer 1

The word in the #mercurial IRC channel is that subrepos will continue to work as they do, and support will grow. For example currently the 'hg status' command isn't subrepo aware -- it works, it just doesn't recurse, but that in the future it will be. However, the current behaviors, fileformats (.hgsub and .hgsubstate) will only be changed in backward compatible ways.

So, go ahead and count on it now, and look forward to it getting better.

P.S. As of mercurial 1.4.2 the subrepos can now be subversion repos, so you can use a mercurial parent and a svn kid.

Kenosis

So there is no clear roadmap for this feature? Say, in hg 1.6 (or 1.7) it should be nearly complete, or something similar? – Chill

It's complete enough to use now. Some workflows will be a little less cumbersome going forward, but it's done now. – Kenosis

Answer 2

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).

Toffeenosed

My use case is #2 in your first list. – Chill