A thought on subrepos

[Benoît Allard]

Greg Ward wrote:
> On 14 April 2011, Matt Mackall said:
>> It seems many projects with subrepos are structured like:
>>
>> app/ <- main repo
>>  lib/ <- a subrepo
>>
>> This is perhaps the most obvious way to do things, but is not really
>> ideal. A better way is:
>>
>> build/ <- main repo
>>  app/ <- subrepo
>>  lib/ <- subrepo
> 
> I've been having similar thoughts, but I don't know how to solve the
> central problem: if I break our overgrown, entangled,
> single-giant-source-tree up into multiple repos, how do developers get
> a working build environment without checking out *everything*.  (If
> you have to checkout *everything*, then why bother splitting up the
> tree?)
> 
> Let me make it a little more clear.  Our source tree looks something
> like this:
> 
>   backend/
>     lib1/
>     lib2/
>     stuff/
>       lib3/
>       app1/
>       lib4/
>     app2/
>     morestuff/
>       lib5/
>       app3/
>   libs/
>     lib6/
>     lib7/
>     ...
>     lib15/
>   db/
>     schema1/
>     schema2/
>     lib16/
>     lib17/
>   web/
>     lib18/
>     app4/
>     app5/
>   frontend/
>     app6/
>     app7/
> 
> ...and so on, and so on.  (We build ~300 individual apps, ranging from
> ridiculously tiny to impressively large.  There are probably ~100
> distinct libraries, but I've never really counted.)
> 
> Let's say I want to split this up: there's no reason for backend
> developers to have to see web or frontend code, and there's no reason
> for frontend developers to have to see db or backend code.  But both
> web and backend developers need db, and everyone needs libs.
> 

Hi Greg,

You're not the only one with this kind of troubles. We have over there 
almost 100 repositories, and multiple build artifact. Each artifact 
needs a specific subset of the repositories. We built our own tool to 
help us achieve that purpose.

Thinking about using subrepositories, I guess a solution for this could 
be to have multiple .hgsub files. One that specify what the web 
developers needs, one for the backend developers, one for the developers 
of app X, and one for the buildsystem. I don't think that branching in 
this case would be a good idea, maybe a modular .hgsub, or putting 
.hgsub as a symbolic link to one of the existent say `subconf` ... Or 
being able to specify the .hgsub to use as an aditionnal parameter could 
also be an idea ...

Just some more thought ...

Regards,
Benoît.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6370 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110418/3a05725a/attachment.bin>