On Friday 30 September 2016 19:38:19 Shurmer, Jordan wrote: > Hello, > > This seems like just the thing that Git Submodules may be useful for: > https://git-scm.com/book/en/v2/Git-Tools-Submodules > > IF each sling module is its own repo there could conceivably still be one > parent repo of some kind, which has a submodule for each other repo. > Hope that helps the discussion!
Jordan, please follow my provided links and have a look. Regards, O. > Thanks, > Jordan Shurmer > > -----Original Message----- > From: ianbos...@gmail.com [mailto:ianbos...@gmail.com] On Behalf Of Ian > Boston Sent: Thursday, September 29, 2016 5:52 AM > To: dev@sling.apache.org > Subject: Re: moving sling to git > > 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-de > v+github+-from%3A%22jira%40apache.org%22+-from%3A%22*%40git.apache.org%22#qu > ery:sling-dev%20list%3Aorg.apache.incubator.sling-dev%20github%20-from%3Ajir > a%40apache.org%20-from%3A*%40git.apache.org%20order%3Adate-backward+page:1+s > tate: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/ > > > > > >
