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! Thanks, Jordan Shurmer -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Ian Boston Sent: Thursday, September 29, 2016 5:52 AM To: [email protected] Subject: Re: moving sling to git Hi, On 29 September 2016 at 10:06, Oliver Lietz <[email protected]> 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 > > <[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/ > >
