Feature request: Selective subrepos

[Scott Palmer]

On 2012-02-13, at 7:57 PM, Todd Greer wrote:

> Isaac Jurado, Monday, February 13, 2012 6:14 PM, said:
>> On Tue, Feb 14, 2012 at 12:36 AM, Todd Greer <TGreer at affinegy.com> wrote:
>>> My proposal is to have files like “repo-set-a.hgsub” and 
>>> “repo-set-b.hgsub”, with a command like “hg addsubrepos repo-set-a” to 
>>> specify that this repository should now act as though it has as 
>>> subrepos everything in “repo-set-a.hgsub”. Future pulls, updates, 
>>> pushes, etc. would all act accordingly. Each .hgsub would have its own 
>>> .hgsubstate file. I see this as a new part of the subrepo feature, but it could also be a new extension.
>>> 
>>> As an alternative, the subrepo-set selection could happen at 
>>> clone-time via a command line argument or .hgrc setting.
> 
>> What is the purpose of different subrepo sets?  Is it just a subrepo URL issue or you really are looking to have different .hgsub files
> 
> The first motivation for this is that the cross-platform project I'm currently working on has 37 subrepos, of which 21 are needed on MacOS and 26 are needed on Windows.
> There are:
> 	10 common subrepos
> 	5 Windows-specific subrepos
> 	11 MacOS versions of 'logically common' subrepos
> 	11 Windows versions of 'logically common' subrepos
> 
> Of these, one of the common subrepos changes frequently, a few change occasionally, and most will change only very rarely. The platform-specific subrepos mostly contain binaries for third-party libraries, and can be fairly large. For the 'logically common' subrepos, it would be very nice if they could go to the same directory on each platform, so the "foo" library is always in a certain place, though it would sometimes be "libfoo.so" and sometimes be "foo.dll". This would make our CMake build scripts cleaner.

It sounds like you could make use of a dependency management tool to solve some of these issues.  For what remains, maybe it won't be so bad to simply have them in different sub repos, where some just are used when building on one platform or the other.

You didn't mention what language you were coding in, but I have successfully used Java-based tools like Maven and Gradle for both Java and C++ projects that have cross-platform third-party libraries to manage.  I find Gradle to be a very good tool for this sort of thing.

Scott