On 7/8/14, 1:27 PM, Mark Thomas wrote: > 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.
It may be as easy for tomcat committers but for me personally it is harder. I have checkouts of all "recent" pool and dbcp release tags that I use to research issues reported against different versions of these components. Tomcat users can be reporters of these bugs. I guess for now I if I want to research any of these, I will have to check out tomcat sources. I will be less likely to do that. I am not a tomcat committer and just one commons committer with limited time, so you can take that feedback for what it is worth. Phil > >> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
