commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] git
Date Tue, 08 Jul 2014 17:26:01 GMT
On 7/8/14, 9:46 AM, Konstantin Kolinko wrote:
> 2014-07-05 19:54 GMT+04:00 Phil Steitz <>:
>> 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]
>> 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]

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.

> Best regards,
> Konstantin Kolinko
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message