On Thursday 29 September 2016 09:27:30 Ian Boston wrote: > 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.
Quoting Stefan: "we discussed again the long-debate topic moving from svn to git." > 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. https://issues.apache.org/jira/browse/SLING-3987 https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git Regards, O. > Best Regards > Ian > > On 28 September 2016 at 23:34, Stefan Seifert <sseif...@pro-vision.de> > > 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/
