discussed at the Sling Committer Round Table @ adaptTo() 2016 we discussed again the long-debate topic moving from svn to git. no commiter hat and objection that moving to git creates a real problem. all agreed it would be nice to move to git.
aspects that where discussed: - every module should get it's own git project - including special cases where a module is only a integration test project - this ensures thare is only one "releaseable" artefact per git repository - and git branching/tagging works as expected - most sling modules are quite independent anyway - we need a replacement for the reactor poms - to build groups of related projects, e.g. sling distribution, sling models, testing mocks etc. - and to build all sling sources together - goal is to have an additional git project for each reactor pom/suitable grouping of git projects - as multi repo tooling support e.g. google repo [1] or gitslave [2] could be used - which solution is chosen is not important for the first step and the initial migration - we can solve this late, it's mainly for convenience - this apporach results in a HUGE number of git repos - perhaps 300-350 including reactor poms - because sling is so modular, and has so many bundles already - in the apache github mirror there is only one organization "apache" - all 350 sling projects would be part of this main organization, together with all other apache git projects that are already listed there - other projects like commons, cordova, couchdb are examples haven already a lot of individual git repos - asf currently does not allow apache projects to create their own github organizsation, mainly due to infra restrictions - name pattern for the git repository should be something like "sling-<artifactId>" - we drop the folder grouping from svn today in "extensions", "servlets", "commons" etc. only the hierarchy of artifactId is relevant. - with the prefix "sling-" they - question: how are "contrib" and "samples" repos marked? by another prefix like "sling-contrib-" and "sling-samples"? - no "self-service" for creating git repos - a big problem ist hat asf infra currently does not provide a "self-service" for creating new asf git projects - whenever a new sling module is created a ticket a INFRA is needed to create it, process is blocked until the involved manual steps are completed - perhaps we can talk to infra providing a better solution here, pointing at the 350 git repos we already need only for the start - if this is not solved just creating a new project/module is more complicated than required - only one git repo for contrib and samples? - we briefly discussed to use only one big repo for contrib and samples as a workaround fort the "no self-service" problem, it would then be easy to create new modules at least there - but this is perhaps not a good solution, because it again creates all problems that arise when multiple releasible artifacts are put together in one git repo - and it would make it harder to move something from contrib to "full supported" - committer whiteboards - we also need a solution for the comitter whiteboards - they should be cleaned up before migration leaving only what is still relevant - migration process - the migration process has to be fully scripted, and tested several time in a "lab environment" - we should avoid migration approached that need restructuring the svn hierarchy before migration (e.g. "flat list of all modules"), because this make impact the migration of svn history to the individual git repos - we may need to write our own migration script handling the specifics of the current svn folder structure and creating the full list of individual git repos locally from it (first migrate to a single git repo and then splitting it up preserving history for each modules folder). those local created git repos can then be pushed to the individual asf git repos. - contact infra - before we take further steps we should ask infra for it's opinion - e.g. by creating a jira ticket and describing the planned steps, and that this would result in a huge number of repos stefan [1] https://code.google.com/p/git-repo/ [2] http://gitslave.sourceforge.net/
