On 09/07/2014 04:38, Phil Steitz wrote: > 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.
As DBCP 2.0 and Pool 2.0 settle down I'd expect Tomcat to be pointing to revisions that map to release tags most of the time. I don't think you'll need to checkout the Tomcat sources. The simplest way I can think of for you to debug an issue with the same code Tomcat is using is: 1. Check the svn:mergeinfo for the Tomcat release reporting the problem: e.g. http://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_9/java/org/apache/tomcat/dbcp/dbcp2/ and http://svn.apache.org/viewvc/tomcat/tc8.0.x/tags/TOMCAT_8_0_9/java/org/apache/tomcat/dbcp/pool2/ for the 8.0.9 release. 2. svn up to those revisions in your checkouts of pool2 and dbcp2 trunk. It is a little more work than what you have to do at the moment (look up two files and do two svn ups rather than lookup one file and then reconfigure dependencies) but it isn't that much (particularly compared to how long dbcp2 and pool2 issues tend to take to debug). Tomcat hasn't yet (and has no plans) to cherry pick commits so it should always be possible to svn up to the particular version Tomcat picked. Mark > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
