I have worked with large single git repositories containing hundreds of modules and it was a pain. It gets expensive and slow as it grows pretty fast. We might not be in the range where it is noticeable now with Sling. And we always ended up in splitting them into single repositories.
All operations (tagging, releasing, cloning/checking out, versioning, forking etc) happen on a single module - so a repository for a module exactly fits this model. Why should I clone a large repository, just to be able to work on commons scheduler for example? Also moving stuff out off / into contrib is totally easy with separate modules. We have a modular setup, so we should account for it. And if we stick with a single repository, why do we need to move at all - isn't there the git mirror already? Carsten 2014-10-01 18:29 GMT+02:00 Oliver Lietz <[email protected]>: > On Wednesday 01 October 2014 17:25:50 Carsten Ziegeler wrote: > > I'm not against moving to git, but the number one criteria would be to > have > > a git repository per module. > > To be honest, that is not a criteria. I also don't like one big repo (yet), > but what problem(s) should one repo per module solve (we would than have > between 200 and 300 repos)? > > I don't like to have the complete project source under a module's tag but > the > way it is now on GitHub where a tag for a module only contains that module. > Is it that what you want to get from one repo per module? > > Checking out/clone a complete big repo shouldn't be expensive - or several > like bundles, contrib, installer, launchpad, parent, performance, samples, > site, testing, tooling (which makes it harder to move modules between > bundles > and contrib but this is a different story). > > O. > > > Carsten > > > > 2014-10-01 16:00 GMT+02:00 Oliver Lietz <[email protected]>: > > > Please discuss on list and add your findings to the wiki: > > > > > > > > > > https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to > > > +Git > > > > > > Thanks, > > > O. > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
