Le jeudi 13 février 2014 08:27:14 Jason van Zyl a écrit : > On Feb 13, 2014, at 1:36 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > > the only show stopper I know is for svn trunk which contains a lot of > > components > > > > so -1 for plugins, shared, skins, resources > > Why wouldn't you put something with its own release cycle in its own > repository? because plugins = 44 entries, shared = 20 entries, skins = 6 entries, resources = 5 entries sum = 75 entries
each entry would mean 1 git repo + 1Jenkins job (or even more, since plugins have multiple Jenkins jobs: 1 for Maven 2.2.x, 1 for Maven 3.0.x, 1 for Maven 3.1.x) IMHO, we're not ready for such granularity, neither at git nor Jenkins level > > but no problem for me for other release roots containing only one > > component > > [1] > > > > notice I don't see much gain: did we get much patches for components > > already in git? did nobody send a patch through github for a svn > > component replicated to github? Is everybody fluent with git (I still ses > > much "merge" commits in git) > > So what's the rationale, really? (apart from bashing one scm over the > > other, in one or another direction) > > The biggest win for me is working on branches. Working with branches in SVN > is horrible, only worse in p4 which is saying a lot. what is "p4"? which component from the 75 previous entries have branches? should require branches? > The ability to easily > create branches, squash commits, incrementally improve them without fear. I > constantly rebase against master and it's really easy with all the great > tools like GitX, GitTower, or SourceTree to easily see changes. The Eclipse > support for Git is a million times better, and doing anything Git related > with JGit in Java is always a pleasure (because the #2 CGit guy, wrote > JGit) do you mean you intend to contribute to other components than core? > > As far as potential contribution if you look at Apache projects at Github > there are varying numbers of forks and pull requests but for some of them > it's pretty significant. > > But for me it's a primarily a personal workflow issue. > > > So I'm -0 on such a change for parts where I feel it would be feasible > > > > Regards, > > > > Hervé > > > > [1] > > https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/d > > ist-tool-check-source-release.html> > > Le mercredi 12 février 2014 22:37:36 Jason van Zyl a écrit : > >> Can we start the process of converting everything to Git. I don't really > >> see any benefit in using Subversion any longer. > >> > >> If so then we should just get together for a day and convert them and > >> then > >> get infra to use what we converted to do the flip. > >> > >> Jason (who would be happy to never execute svn again) > >> --------------------------------------------------------------------- > >> 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 > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > http://twitter.com/takari_io > --------------------------------------------------------- > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
