Herve, I think, first of all, we should write a list with exact names of git repositories for which INFRA will crate them in git1-us-west.apache.org/repos/asf and mirror in github.com/apache
And then the authors.txt. In my case I did not migrate tags and branches which is my problem given in my example with previous e-mail. On Sat, Oct 7, 2017 at 3:48 PM, Tibor Digana <tibordig...@apache.org> wrote: > Herve, > I think making the tag as I wanted would not be possible in git. > > Let's make it with all 78 projects. > In 2016 I migrated my svn project "audit" located in sub-folder behind > trunk (trunk/libs/audit) to git which is exactly what we need to do in ASF. > > In our case the commands would be 99% the same. The 1% is the source SVN > URL and target GitHub URL. That's all. Then if we provide INFRA with bunch > of commands like these then they will only execute them with their > permissions. > I do not think they will give me admin permissions to make it. > > git svn clone --no-metadata --authors-file=E:\*authors.txt* http:// > ***/svn/***/*trunk/libs/audit audit* > git config --global user.name "*** ***" > git config --global user.email "***@***.***" > git remote add origin https://***@github.com/apache/*maven-clean-plugin* > .git > git push -u origin --all > > I observed the *authors.txt* from command > *svn log -q* > Each person from between first two pipes, e.g.: > r1234567 | tibordigana | 2015-10-19 02:20:00 > > Every developer added e-mail and full name, i.e.: > tibordigana = Tibor Digana <tibordig...@apache.org> > etc. > > This list of users which should be created in prior to contact INFRA. > Not all users are active after years but it would be nice to include them > too. > This list of users is one thing which cannot be automated! > > > > > On Sat, Oct 7, 2017 at 2:48 PM, Tibor Digana <tibordig...@apache.org> > wrote: > >> In my company I have such situation in SVN. Making a tag from subfolder. >> Git always makes the tag from the root, right? >> Let's google something... >> >> On Sat, Oct 7, 2017 at 2:47 PM, Tibor Digana <tibor.dig...@googlemail.com >> > wrote: >> >>> In my company I have such situation. >>> Making a tag from subfolder. >>> Git always makes the tag from the root, right? >>> Let's google something... >>> >>> On Sat, Oct 7, 2017 at 2:05 PM, Hervé BOUTEMY <herve.bout...@free.fr> >>> wrote: >>> >>>> thanks for your interest and feedback >>>> >>>> Le samedi 7 octobre 2017, 12:00:32 CEST Tibor Digana a écrit : >>>> > 78 is too much. >>>> notice that there would also be a question on the git repos naming >>>> convention, >>>> to avoid flat 78 names but keep at least 3 meaningful groups (plugins, >>>> shared, >>>> resources: I think this is not absolutely necessary for doxia-tools) >>>> >>>> > There is no problem to trigger release over sub-folders and tag it >>>> with >>>> > prefix which is already done in SVN. >>>> is it supported by maven-release plugin with git? >>>> >>>> notice I did not know that git was able to tag only a subtree: but I >>>> knew I >>>> don't yet understand every aspect of git magic... :) >>>> >>>> > The CI build can always trigger the root and Jenkinsfile would have 41 >>>> > stages for plugins, 26 stages for Shared, etc. >>>> > It can be done in Jenkinsfile and so the shell would not throw >>>> exception >>>> > but status would be set instead and goes to the next stage. >>>> > I do not know how to detect in GitSCM which sub-folder(s) received >>>> but I >>>> > guess this can be investigated. >>>> +1 >>>> but I don't know where to look for myself: on that point, I hope to >>>> have some >>>> help from Jenkinsfile experts >>>> and eventually start with svn, to have something before the git >>>> migration >>>> >>>> > Then it can be a kind of switch-case over committed folders in >>>> Jenkinsfile. >>>> > This means that every time another stage/sub-folder is shown in >>>> Pipeline >>>> > which will be messy in the UI. :( >>>> notice that we can perhaps split the repos in less parts than we have >>>> components: on plugins, for example, we already have 4 categories [1] >>>> which >>>> would avoid 1 repo with 41 plugins, but more something like 6+10+10+15 >>>> I suppose we could do the same for shared (reporting folder comes to my >>>> mind) >>>> >>>> The key feasibility issue is the capacity to release a sub-component >>>> from git >>>> with maven-release-plugin, IMHO >>>> (taking apart the git purists idea of 1 lifecycle = 1 git repo) >>>> >>>> Regards, >>>> >>>> Hervé >>>> >>>> >>>> [1] http://maven.apache.org/plugins/ >>>> > >>>> > On Sat, Oct 7, 2017 at 4:17 AM, Hervé BOUTEMY <herve.bout...@free.fr> >>>> wrote: >>>> > > There are 6 svn locations without any special complexity that are >>>> waiting >>>> > > for >>>> > > a volunteer for git migration for a few years but nobody does >>>> anything >>>> > > about: >>>> > > I started 3 days ago to ask for help about it and got pretty no >>>> feedback >>>> > > [1] >>>> > > >>>> > > then there are the 4 complex svn locations (plugins, shared, >>>> resources, >>>> > > doxia- >>>> > > tools) that require much more work: I suppose we can't tell git >>>> migration >>>> > > is >>>> > > abandoned, but it will require someone to work on it seriously >>>> > > Remember that the key question [2] is: do we transform these 4 svn >>>> > > locations >>>> > > into 41 +26 + 6 + 5 = 78 independent git repos? >>>> > > Yes, I told that Jenkins configuration is one key aspect we need a >>>> > > strategy >>>> > > about, in parallel with git strategy. >>>> > > >>>> > > then there will be the remaining cases where we need to decide: >>>> lower >>>> > > impact, >>>> > > lower priority. >>>> > > >>>> > > >>>> > > Summary: nothing is abandoned, but: >>>> > > - simple cases: no volunteer to do the job >>>> > > - hard cases: is there a volunteer either to define a strategy or >>>> do some >>>> > > work >>>> > > on it? >>>> > > >>>> > > >>>> > > Regards, >>>> > > >>>> > > Hervé >>>> > > >>>> > > [1] https://lists.apache.org/thread.html/ >>>> > > edf3642a7bdd515f0cad421c25589741819446463614bf0515e56dbe@ >>>> > > %3Cdev.maven.apache.org%3E >>>> > > >>>> > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git >>>> > > +Migration#GitMigration-Migratinganaggregatortreeintoacollec >>>> tionofgitrepos >>>> > > >>>> > > Le vendredi 6 octobre 2017, 20:35:45 CEST Arnaud Héritier a écrit : >>>> > > > But did we completely abandoned the idea of moving everything to >>>> git ? >>>> > > > The CI setup was the main stop for it ? >>>> > > > >>>> > > > On Fri, Oct 6, 2017 at 8:05 PM, Hervé BOUTEMY < >>>> herve.bout...@free.fr> >>>> > > >>>> > > wrote: >>>> > > > > I was expecting the usual litany >>>> > > > > >>>> > > > > what I'm not confident currently with pipeline on Maven core is >>>> that >>>> > > > > we >>>> > > > > have >>>> > > > > for example the "maven-3.x-jenkinsfile/MNG-6242 - build #1 - >>>> null" >>>> > > > > message, >>>> > > > > with this "null" part that makes me wonder if we are using it as >>>> > > >>>> > > expected. >>>> > > >>>> > > > > And for large multi-module svn trunks (the ones we don't >>>> migrate to >>>> > > >>>> > > git: >>>> > > > > mainly plugins and shared), is there a solution to rebuild just >>>> > > > > changed >>>> > > > > modules? >>>> > > > > >>>> > > > > ideally, the rebuild when a SNAPSHOT dependency is published >>>> would >>>> > > > > have >>>> > > > > been a >>>> > > > > plus, but this is sufficiently a rare use that I won't be >>>> extremist >>>> > > > > >>>> > > > > >>>> > > > > Then IIUC, this migration job is one additional TODO for me... >>>> > > > > >>>> > > > > Regards, >>>> > > > > >>>> > > > > Hervé >>>> > > > > >>>> > > > > Le vendredi 6 octobre 2017, 17:46:53 CEST Arnaud Héritier a >>>> écrit : >>>> > > > > > I agree that we should use pipeline nowdays >>>> > > > > > perhaps a shared lib if we want to standardize some stuffs >>>> and a set >>>> > > >>>> > > of >>>> > > >>>> > > > > > multi-branches jobs (or org folder but it requires GitHub :( ) >>>> > > > > > >>>> > > > > > On Fri, Oct 6, 2017 at 9:16 AM, Stephen Connolly < >>>> > > > > > >>>> > > > > > stephen.alan.conno...@gmail.com> wrote: >>>> > > > > > > On Fri 6 Oct 2017 at 06:32, Hervé BOUTEMY < >>>> herve.bout...@free.fr> >>>> > > > > >>>> > > > > wrote: >>>> > > > > > > > I just fixed a few failing jobs [1] to have again a usable >>>> > > >>>> > > Jenkins. >>>> > > >>>> > > > > > > > Now I'm facing some issues, I suppose caused by newer >>>> Jenkins >>>> > > > > >>>> > > > > versions: >>>> > > > > > > > - Maven 3.0.5 causes NoSuchMethodError: >>>> > > > > > > > o.c.plexus.util.xml.pull. >>>> > > > > > > >>>> > > > > > > MXParser >>>> > > > > > > >>>> > > > > > > > [2] >>>> > > > > > > > - I had to switch to JDK 8 for maven-plugin-tools job, >>>> since JDK >>>> > > > > >>>> > > > > causes >>>> > > > > >>>> > > > > > > > failures (looks like Jenkins uses a hack to inject JDK 7 >>>> as a >>>> > > >>>> > > tool >>>> > > >>>> > > > > while >>>> > > > > >>>> > > > > > > > the >>>> > > > > > > > build JVM is Java 8) >>>> > > > > > > > >>>> > > > > > > > Should we drop Maven 3.0.5 builds and JDK 7? >>>> > > > > > > > Notice I didn't check which is the minimum Maven version >>>> > > >>>> > > required... >>>> > > >>>> > > > > > > > Or perhaps simply don't use the Jenkins Maven plugin with >>>> this >>>> > > >>>> > > Maven >>>> > > >>>> > > > > > > 3.0.5 >>>> > > > > > > >>>> > > > > > > > or >>>> > > > > > > > JDK 7 configuration: default build as Jenkins Maven >>>> plugin with >>>> > > >>>> > > JDK >>>> > > >>>> > > > > 8 + >>>> > > > > >>>> > > > > > > > latest >>>> > > > > > > > Maven, and other configurations as scripted jobs? >>>> > > > > > > >>>> > > > > > > http://javaadventure.blogspot.ie/2013/11/jenkins-maven-job-> >>>> > >>>> > > > > >>>> > > > > type-considered-evil.html >>>> > > > > >>>> > > > > > > <http://javaadventure.blogspot.ie/2013/11/jenkins-> > >>>> > > > > >>>> > > > > maven-job-type-considered-evil.html?m=1> >>>> > > > > >>>> > > > > > > We should stop using the evil job type as it’s minimum Java >>>> > > >>>> > > version is >>>> > > >>>> > > > > > > dictated by Jenkins’ Java minimum. >>>> > > > > > > >>>> > > > > > > > We need to define our common strategy and have a >>>> consistent >>>> > > > > > > > configuration >>>> > > > > > > > for >>>> > > > > > > > every job understood by everybody >>>> > > > > > > >>>> > > > > > > I recommend Jenkinsfile and the `withMaven` wrapper >>>> > > > > > > >>>> > > > > > > > Regards, >>>> > > > > > > > >>>> > > > > > > > Hervé >>>> > > > > > > > >>>> > > > > > > > [1] https://builds.apache.org/view/M-R/view/Maven/ >>>> > > > > > > > >>>> > > > > > > > [2] >>>> > > > > > > > https://builds.apache.org/view/M-R/view/Maven/job/maven-> >>>> > >>>> > > > > > > >>>> > > > > > > plugin-tools-jdk-1.7/162/console >>>> > > > > > > >>>> > > > > > > > ------------------------------ >>>> ------------------------------ >>>> > > > > >>>> > > > > --------- >>>> > > > > >>>> > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> > > > > > > > For additional commands, e-mail: >>>> dev-h...@maven.apache.org >>>> > > > > > > > >>>> > > > > > > > -- >>>> > > > > > > >>>> > > > > > > Sent from my phone >>>> > > > > >>>> > > > > ------------------------------------------------------------ >>>> --------- >>>> > > > > 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 >>>> >>>> >>> >>> >>> -- >>> Cheers >>> Tibor >>> >> >> >
