When does it make sense to use subrepositories?

[Angel Ezquerra]

On Apr 19, 2013 10:03 PM, "Matt Mackall" <mpm at selenic.com> wrote:
>
> 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.
>

Matt,

thank you for the edit. I think the text is much better, and more nuanced
now.

One thing that I think is missing,  is a short explanation of when using
subrepos is appropriate (as in the largefiles section). I found that your
original answer on this thread was a great summary of when to use subrepos.
Perhaps that could be adapted and added there?

I could do it myself but I don't feel that my opinion on subrepos is
negative enough to write on the "features of last resort" page :-)

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20130420/386eed5f/attachment-0002.html>