Hi,
On 29 September 2016 at 10:06, Oliver Lietz <apa...@oliverlietz.de> wrote: > 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 Thank you for the pointers I had searched the archives with [1] but only found [2], hence my concern that Sling had reverted to offline decision making, given the activity landing in my inbox from adaptTo. My concern was unfounded. There has been discussion online and the decision has been made. I missed it all due to other commitments. Ignore my comments on the detail. Best Regards Ian 1 http://markmail.org/search/?q=sling-dev+list%3Aorg.apache.incubator.sling-dev+github+-from%3A%22jira%40apache.org%22+-from%3A%22*%40git.apache.org%22#query:sling-dev%20list%3Aorg.apache.incubator.sling-dev%20github%20-from%3Ajira%40apache.org%20-from%3A*%40git.apache.org%20order%3Adate-backward+page:1+state:facets 2 http://markmail.org/thread/u32gblzpjairkc3a > > > 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/ > >
