When does it make sense to use subrepositories?

[Matt Mackall]

On Fri, 2013-04-19 at 14:37 +0200, Angel Ezquerra wrote:
> On Thu, Apr 18, 2013 at 11:40 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Thu, 2013-04-18 at 23:04 +0200, Angel Ezquerra wrote:
> >> On Thu, Apr 18, 2013 at 8:52 PM, Matt Mackall <mpm at selenic.com> wrote:
> >> > On Thu, 2013-04-18 at 09:36 -0700, v wrote:
> >> >> I've just backed out of several hours' work transitioning a set of related
> >> >> projects from one repository to a group of subrepositories. Having been
> >> >> through this a few times before, I always seem to end up with one of two
> >> >> scenarios:
> >> >>
> >> >> - If changes to one project are usually associated with changes to other
> >> >> related projects, put them in the same repository.
> >> >> - Otherwise, use separate repositories, and handle the relationship with you
> >> >> favourite dependency management solution. If you really want to do this with
> >> >> your SCM, then use guestrepos.
> >> >>
> >> >> I do acknowledge that subrepos are now declared "a feature of last resort",
> >> >> but I'm wondering what this situation is. Someone paid for them to be
> >> >> developed, so they must be useful somewhere!
> >> >
> >> > Most people are unclear on the fundamental purpose of version control.
> >> > They think of VCSes as first and foremost a tool to synchronize code
> >> > between developers. But this is wrong; it is a description of rsync. The
> >> > primary purpose of an VCS is to precisely track old states of the
> >> > project for future reference.
> >> >
> >> > With that in mind, ask yourself the question:
> >> >
> >> > "Do I need to be able to reproduce an exact combination of independent
> >> > projects from the past in the future?"
> >> >
> >> > In other words, "do I need _version control_ on my combination of
> >> > projects?"
> >> >
> >> > If the answer is yes, your options are:
> >> >
> >> > - check everything into one repo and hope you don't have to merge in
> >> > "upstream" changes often
> >> > - use subrepos
> >>
> >> I could not have said it better! I think subrepos cover the
> >> requirement that Matt mentioned pretty well, and that is a very
> >> important and common requirement.
> >>
> >> I'm very happy to see that Matt did not immediately refer to them as a
> >> feature of last resort.
> >
> > It is absolutely a feature of last resort. I do not know why people have
> > so much trouble parsing the semantics of that.
> 
> Personally when I read that something is "a feature of last resort" I
> used to imagine Bruce Willis jumping down a 40 story building, guns
> blazing, while the bad guys shoot at him in one of the Die Hard
> movies... Using subrepos is just not that exciting :-)
> 
> > It is a feature: it does things you can't do with normal Mercurial.
> > It is a last resort: you do not want to use it if you don't need to.
> 
> I think now I get what you mean, and under that definition I agree
> with you. However, on the "FeaturesOfLastResort" wiki page, it says:
> 
> "These features exist for supporting some (usually legacy) use cases,
> but are not considered best practice.

You're right, this statement is a little bit strong for subrepos. There
are uses of subrepos that I would consider best practice insofar as the
alternatives are worse.

This paragraph is mostly written with the EOL and keyword extensions in
mind. I'll see if I can make it more inclusive.

-- 
Mathematics is the supreme nostalgia of our time.