On Wednesday 28 September 2016 22:34:48 Stefan Seifert wrote: > 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"
I really prefer the simple rule "one module : one repo". You should be able to start new modules/repos anywhere and later make them an official ASF/Sling master repo. > - committer whiteboards > - we also need a solution for the comitter whiteboards > - they should be cleaned up before migration leaving only what is still > relevant Per committer whiteboards can easily moved to personal repos on GitHub, Bitbucket or whatever. > - 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 https://issues.apache.org/jira/browse/SLING-3987 https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git Regards, O. > stefan > > [1] https://code.google.com/p/git-repo/ > [2] http://gitslave.sourceforge.net/
