2016-07-15 10:29 GMT+03:00 Jochen Wiedmann <jochen.wiedm...@gmail.com>: > Hi, > > for the record: This vote has passes with three binding votes (Gary, > Stian, myself). I am ignoring the opposition voiced by Konstantin > Kolinko, because I don't think. that Tomcat's got a say. Besides, > there are several options, that Tomcat can follow:
OK, agreed. This "Tomcat's got a say" is a wrong wording. I am not Tomcat. We are individuals here. PMC position is expressed via votes, or at least via a discussion. There was none at dev@tomcat. I am just stating a technical issue and that your change will impact a neighbor project. You may go on. I think that the likely solution at Tomcat side will be to create a "vendor" branch in ASF Subversion repository. So instead of an in-house in-tree merge there will be a copy of the code, and some manual work to update it. There was no discussion at @tomcat ML on further steps yet. It is just how such issues are usually solved > 1.) Use a shaded release jar, rather than forked sources. This relies on timely releases at Commons side. It is also likely to delay important fixes by several days. Tomcat used build-time shading for Commons Pool and Commons DBCP, but it switched to a fork at DBCP 2 time. One reason was that DBCP2 was in active development and there were no releases for awhile. Shading is used to avoid conflict with libraries used in web applications deployed on Tomcat. > Matt wrote: > They can use the svn mirror on GitHub, too, unless that's against Apache > policy. Maybe. I just tested that "svn ls", "svn log", "svn diff -c" on https://github.com/apache/commons-fileupload.git are working. E.g. svn log --limit 10 https://github.com/apache/commons-fileupload.git/trunk/ "svn ls" is rather slow, but the two others are usable. Thus it is possible to do svn merges from them. I do not know whether those revision number are stable, though. (I was more pessimistic as my tests with svn log on GitHub two years ago were not successful. It is good that it works.) > 2.) Migrate to git itself. This should actually simplify maintenance > of the current fork. I do not think that migrating Tomcat will simplify maintenance. Is there a good workflow, and support from tools? A closing note: To be compatible with Git, to be able to use Git and Subversion interchangeably on the same sources, the only real requirement for a project is to remove svn:keywords. You will need to remove them anyway and I think it is a lot easier to do so before svn-git migration. http://svn.apache.org/viewvc?view=revision&revision=1561173 http://svn.apache.org/viewvc?view=revision&revision=1561174 For Tomcat I did it in two steps: Step 1) search for $Id and remove those lines. Then search for '$' as an additional check for missed keywords. Tomcat code had several unusual keywords left from CVS time. Step 2) svn propdel svn:keywords --depth infinity . Use "svn status" or "svn diff" to verify changes before committing. If "svn st" shows that some files have both metadata and content changes, it means that those files were missed on step 1). Sample output of "svn st", on a test repository, note the double "MM": [[[ MM test.txt ]]] "svn diff" shows the textual change: [[[ Index: test.txt =================================================================== --- test.txt (revision 54) +++ test.txt (working copy) @@ -1 +1 @@ -$Id$ +$Id: test.txt 54 2016-07-18 07:51:21Z kkolinko $ Property changes on: test.txt ___________________________________________________________________ Deleted: svn:keywords ## -1 +0,0 ## -Id \ No newline at end of property ]]] Second, you can add ".gitignore" file. This is not required, but it is rather convenient. Tomcat did this and it can be developed in parallel using git or using svn, There is no real need to migrate a project to git to be compatible with git and to be able to accept pull requests. I agree that migrating to git will make workflow easier. Thus I think it will beneficial to your project. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
