[asterisk-scf-dev] Consolidate git repos?

[Kevin P. Fleming]

On 10/13/2010 07:08 AM, Russell Bryant wrote:

> What would be the downside of consolidating the git repos such that there isn't a separate repo per component?  As I've started thinking about the process of submitting a change, it occurs to me that making and submitting a change for review to core slice and all of the components that use it could be quite cumbersome.  This is going to be even more of an issue a year or two from now when the number of components continues to grow.
> 
> Perhaps a happy middle ground would be to keep slice and cmake as separate, but put all of the components together?  At least that way the gitall stuff can go away and a patch that changes slice and the components is just two patches / code reviews and not 10 ... or 50.

We've used separate git repos for a number of reasons, but one of the
biggest is that it is the 'git way', which is driven by the fact that
branches and tags in git are for the *entire* repository (unlike
Subversion, where they are just a directory copy in the tree). If two
components are in the same git repo, they'd have to have identical
branching and tagging schedules and releases, or the branches/tags would
have to incorporate component names in their own names. In addition,
since it's not possible to partially clone a git repo, if someone wanted
to work on a single component, they'd be forced to clone the entire
consolidated repo.

Personally I see no problem with a patch that changes the published APIs
being posted, reviewed and merged on its own before the changes to the
components that implement those APIs (and eventually the components that
consume the APIs as well). We may learn later that it's more cumbersome
than we are expecting, who knows :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming at digium.com
Check us out at www.digium.com & www.asterisk.org