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. Don't the releases at least use released versions? 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. Cutting releases from trunk pulls will make it a lot harder to research issues. 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? 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. Phil > > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > 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
