I updated the page to mark in green the repos that are ready to migrate: just need the job to be done (with the help of infra, I suppose) with immediate one to one migration
We can in parallel work on organizing more complex 1 to many migration plan Thank you for your help on this tedious work that exhausted previous volunteers... Regards, Hervé Le dimanche 18 juin 2017, 12:12:54 CEST Paul Hammant a écrit : > Choose one to start with, is what I would do. > > git svn clone of a trunk only, then make that master. branch/tag history > can be retained in Subversion but also up on MavenCentral as > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > operation by specifying the first Svn commit for the module in question, > it'll need many hours to iterate over all commits to pluck out the ones > pertinent to the trunk of that module. > > GitHub only allows a single effective 'parent directory' for repos, so > instead of the general github.com/apache org (and in lieu of > github.com/apache/maven/<repo-name> which is what you'd actually want), we > could do github.com/apache-maven/<repo-name>. > > I volunteer for some of the work. Err, maybe I should read those > confluence pages. > > - Paul > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > yes, git is really ubiquitous now and nowadays could perhaps help some > > contributions > > here is our tracking of git migration [1] > > > > there are a few entries that we could move if someone takes the job: > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to > > many > > git repos that are documented but not solved yet > > Plugins and shared components are the 2 big repos, with respectively 41 > > and 26 > > parts if we switch to git that look hard to manage if we don't have a > > plan. > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins > > side. > > > > Skins is perhaps not an issue any more now that we deprecated 3 old skins, > > then only 2 skins remain. Pom would be feasible now that I reworked Maven > > parent poms to be only in one global release: just the history migration > > could > > be tricky given this exact rework :) > > > > > > Then we can move forward: > > - just do it for some svn repos > > - a plan, particularly on Jenkins side, has to be found for plugins and > > shared > > > > any taker for some of the work? > > > > Regards, > > > > Hervé > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > In order to be able to build a composite 'trunk' for all components of > > > > maven (that are org.apache.*) can we move the remaining things left in > > > > Subversion to Git, and mirror them to Github? > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > > > > experience > > > > that felt like a single trunk that would be cloneable in a single > > > > command. > > > > > This have been discussed, afaik, for the plugins already. That would > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
