When does it make sense to use subrepositories?

[Carsten Fuchs]

Am 2013-04-18 22:42, schrieb Matt Mackall:
>> Personally, I very much like the approach that is explained in this blog post:
>> http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/
>>
>> It's explained for Git, but the beauty of this approach is that it also works with
>> Mercurial, and even better, its very simple, because it only uses the "normal" feature
>> set of a version control system. No extras for subtree, submodules, subrepos, sub...
>> required.   ;-)
>
> This page describes -the most basic feature of DVCS- as if it were a
> special technique. Yes, it's very easy to track an upstream vendor repo
> in a DVCS, it's called 'clone'.

Well, sure, it's called 'clone' if you're tracking only exactly one third party package 
such as the Wordpress in the example. This "technique" is more interesting if you're 
tracking several third party packages at once. Please see below.

And in this situation, if you're a SVN user who has never used a DVCS before and are 
investigating how to migrate to one, and if you have used for years what the SVN 
documentation calls "vendor branches" and are wondering how these map into the world of 
DVCS, and if every search query that you enter shouts back solutions that all begin with 
"sub..." -- then this is trivial in hindsight, but not then.

> But that won't help you when you want to track customized versions of
> 100 third-party packages in one project, like the operating system image
> in your set-top box.

It depends: If you want to track these third party-packages at the finest possible 
granularity, commit for commit, then of course this "vendor branch" approach is far too 
cumbersome.

But if you want to track a number of third party libraries for your own programming 
project, where the the third party libraries are updated only infrequently (e.g. with 
each official stable or major release), and you still want to maintain your own 
customizations to each, then it is quite useful:

Each third-party library would be kept in a subdirectory of it's own, and the commits in 
the "vendor" branch would never contain anything other than the subdirectories with the 
third-party libraries. If a new stable third party library is released, copy it over the 
latest commit in the "vendor" branch, merge back to default, done. Customizations to a 
third party library would be directly done in the default branch (or a branch 
semantically close to it), not in "vendor".

Yes, this is not a "special technique", just like Subversions vendor branches are no 
special technique neither. But it's a concept or strategy to manage third party 
libraries (with infrequent updates but occasional customizations) that -- if you're new 
-- is not *that* self-suggesting either, imho.

Best regards,
Carsten