On 08/07/2014 18:26, Phil Steitz wrote: > On 7/8/14, 9:46 AM, Konstantin Kolinko wrote: >> 2014-07-05 19:54 GMT+04:00 Phil Steitz <phil.ste...@gmail.com>: >>> From the looks of [1] and the repo list at [2] it looks like all we >>> have to do to get started is open an infra JIRA and there should not >>> be a problem starting with [math] by itself. Other commons >>> components can follow as and when they feel like it. I am not a >>> very experienced git user / admin, but I think some of us are >>> (right, Luc?) Any objections to opening the infra ticket to get >>> this moving? >>> >> >> I think someone has to remove svn keywords from the source files. They >> make no sense if source code is stored in Git. >> >> E.g. the following file [1] uses $Id$, $Revision$ and $Date$. >> >> [1] >> http://svn.apache.org/viewvc/commons/proper/math/trunk/build.xml?view=markup >> >> >>> Other commons >>> components can follow as and when they feel like it. >> I do not have objection for math, but I think that it would be some >> problem if any of {BCEL, codec, DBCP2, fileupload, pool2} were >> converted to Git, as Apache Tomcat borrows code from those projects >> using svn merges to keep up with the changes. [2] It is not a show >> stopper, but just some nuisance that I do not yet know how to deal >> with. >> >> [2] http://svn.apache.org/viewvc/tomcat/trunk/SVN-MERGE.txt?view=markup > > Wow. /trunk/... Last time I looked at tomcat builds they were at > least using tags.
We've switched to using svn directly rather than released src tarballs because waiting for Commons to do a Pool and the a DBCP release before we do a Tomcat release adds way to much delay (at least a week). We have the ability to pick a revision number. Normally it corresponds to a tag but of there is a fix we need/want in trunk then we can use that. > Don't the releases at least use released versions? Not always no. The more frequently DBCP and Pool release, the more likely it is Tomcat will pull in versions that correspond to tags. > I vaguely recall some ant properties somewhere specifying > release versions and I used to be able to look at these to determine > which versions of [pool] and [dbcp] tomcat releases were using. They are no longer used. > Cutting releases from trunk pulls will make it a lot harder to > research issues. Why? You just have to look at the svn merge info in the tag and that will tell you exactly what Tomcat has used. I'd argue that debugging is easier since the source is now there in the Tomcat repo. > Do you at least record the revision number > somewhere? Or is what you are referring to above just for tomcat > trunk and you somehow back-rev to latest releases when you actually > cut RCs / release branches? See above. > In any case, your point is well-taken. If and when those components > move, we will have to make sure we don't break tomcat's ability to > build using repackaged / filtered sources. To be honest that is Tomcat's problem, not Commons's. I suspect the solution will require using git clients to do the merge but we can cross that bridge when we come to it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
