On Wed, Oct 1, 2014 at 7:29 PM, Oliver Lietz <[email protected]> wrote: > > 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).
Well, tooling can easily solve transplanting histories ( been there, done that ) so let's say we have the following scenarios covered - migrating our big SVN repo to multiple git repositories, preserving history - migrating from a whiteboard git repository to a separate git repository, preserving history I think, as Bertrand mentioned, that we can live with a delay in creating repos, given that we have tooling to migrate from sling-whiteboard to sling-$MODULE. There are already projects which have a largeish number of git repos , see cordova at [1], but we might want to talk to infra first - we'll definitely have a lot of repos.I counted 266 Maven modules in the current checkout. We'll likely have fewer git repos, but even 100 sounds like a lot. Now for that part that I'm not so certain about ... How will this story look for a non-committer trying to get the Sling source in order to inspect it / build it / contribute to it? Do we ask them upfront to install an external tool ( gitslave ) ? Or do we we guarantee that the Launchpad is always buildable outside the reactor by banning SNAPSHOT dependencies or by always deploying bundle SNAPSHOTS to the apache maven repo? Should we build additional scripts to easy checkout? Robert [1]: http://git.apache.org/
