Hi, I fully support moving to Git. I think it would be a mistake to attempt to split the repository into 100s of separate Git repositories as it will make it near impossible for any outsider to work on the code base. I say that from a position of experiencing exactly the same style of re-organisation on a large code base with a similar number of modules. Finding the root cause of a problem takes an order of magnitude more time, and if a pull request has to be applied to several repositories at the same time, good luck. IIUC those that work on all of the code base on a daily basis, have no problem.
Quite apart from the infra issues. Do it with 1 repo, under the ASF banner, not in a independent GitHub organisation. It sounds like this was a long and complex offline discussion. I do hope a decisions of this magnitude was not made, at that time, excluding those members of the community, committers, PMC and ASF Members who were not able to attend the adaptTo conference. Best Regards Ian On 28 September 2016 at 23:34, Stefan Seifert <[email protected]> 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" > > - 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/ > > >
