We already know that maven-plugins is going to be a big PITA unless we just decide to stay with the current git-svn clone and accept it structure.
Having done quite a few migrations I know I'd be spending a truckload of time getting the filter-branch scripts and the rewrites working properly (the advantage being that once it's right for one project it can probably be applied to all of them). I think the many-repo issue can be solved with scripts or tooling, it does not bother me too much. But the current maven-plugins (and to some extent maven-shared) are a problem. Essentially nothing will happen with maven-plugins until someone steps up to do it. Kristian 2014-02-14 9:31 GMT+01:00 Lennart Jörelid <lennart.jore...@gmail.com>: > While I agree that the migration from Subversion to Git can be somewhat > labour-intensive, > it can be an ongoing activity, simply migrating piece by piece. > > Since there is a particular issue with the Maven release plugin creating > what is normally > interpreted as Git branches (as opposed to Git tags) one does normally need > to run some > correct-the-history type scripts following the standard migration. Of > course, the more nonstandard > of a Subversion stucture one originates from, the more complex these > scripts become. > > The migration itself is - in my experience - something fairly > straightforward. > It's the script-to-correct-history phase which follows the VCS migration > that is somewhat cumbersome. > > ... and it therefore becomes important to migrate big repos piece by piece. > > > 2014-02-14 9:23 GMT+01:00 Kristian Rosenvold <kristian.rosenv...@gmail.com > >: > > > I think the main problem with especially maven-plugins is the sheer > amount > > of work required to convert these to individual repositories, especially > > due to the somewhat not-good structure of the current clone. > > > > The others should be fairly straight forward, splitting maven-shared > > included. > > > > Kristian > > > > > > > > > > > > 2014-02-14 9:19 GMT+01:00 Hervé BOUTEMY <herve.bout...@free.fr>: > > > > > No doubt it can be done in general, but the question is on ASF > > (canonical) > > > git > > > repo [1] > > > at the moment, everything seems flat > > > IMHO, some git expert should work with infra to make it more structured > > > > > > Regards, > > > > > > Hervé > > > > > > [1] https://git-wip-us.apache.org/repos/asf > > > > > > Le vendredi 14 février 2014 20:23:34 Fred Cooke a écrit : > > > > I have my private git repo setup in a nested way. No reason you > > couldn't > > > do > > > > that the same for this. > > > > > > > > baseurl/org/apache/mvn/core/componentA.git > > > > > > > > etc. > > > > > > > > Unsure if this addresses your concerns or not, but it's certainly > neat > > > and > > > > tidy at the server end, and the user can duplicate the path structure > > the > > > > same at home. > > > > > > > > Fred. > > > > > > > > On Fri, Feb 14, 2014 at 7:33 PM, Hervé BOUTEMY < > herve.bout...@free.fr > > > >wrote: > > > > > I'm not a git expert: if there are solutions, yes, they have to be > > > found, > > > > > explained, tested, before we launch "convert everything to git" > > > > > > > > > > thank you for any good idea and then any tests from people wanting > > the > > > > > great > > > > > migration to happen (without wreaking havoc) > > > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > Le vendredi 14 février 2014 17:10:07 Mark Derricutt a écrit : > > > > > > Jenkins could build from a super-repo that uses git submodule. > > > > > > > > > > > > Since a quite a few versions ago, git-submodules can now follow a > > > branch > > > > > > rather than a fixed SHA1. > > > > > > > > > > > > So you could build/test monolithically, branch/commit > individually. > > > > > > > > > > > > Compromise maybe? > > > > > > > > > > > > On 14 Feb 2014, at 6:28, Hervé BOUTEMY wrote: > > > > > > > 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 > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > > > > > > > > > > > > -- > > -- > +==============================+ > | Bästa hälsningar, > | [sw. "Best regards"] > | > | Lennart Jörelid > | EAI Architect & Integrator > | > | jGuru Europe AB > | Mölnlycke - Kista > | > | Email: l...@jguru.se > | URL: www.jguru.se > | Phone > | (skype): jgurueurope > | (intl): +46 708 507 603 > | (domestic): 0708 - 507 603 > +==============================+ >
