Good thought. We could ask about a timeline. On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote:
> They are now adding user grouping... I wonder how long before repo grouping > too > > On Sun 18 Jun 2017 at 17:12, Paul Hammant <p...@hammant.org> wrote: > > > 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-Migratinganaggregatortreeintoa > collectionofgitrepos > > > > > > 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 > > > > > > > > > -- > Sent from my phone >
