You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2014/07/05 17:54:08 UTC
[math] git
>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?
Phil
[1] http://www.apache.org/dev/writable-git
[2] https://git-wip-us.apache.org/repos/asf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] git
Posted by Luc Maisonobe <lu...@spaceroots.org>.
Le 05/07/2014 17:54, Phil Steitz a écrit :
>>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?
Big +1 from me.
Luc
>
> Phil
>
> [1] http://www.apache.org/dev/writable-git
> [2] https://git-wip-us.apache.org/repos/asf
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] git
Posted by Mark Thomas <ma...@apache.org>.
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 <ph...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] git
Posted by Phil Steitz <ph...@gmail.com>.
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 <ph...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] git
Posted by Mark Thomas <ma...@apache.org>.
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 <ph...@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] git
Posted by Phil Steitz <ph...@gmail.com>.
On 7/8/14, 9:46 AM, Konstantin Kolinko wrote:
> 2014-07-05 19:54 GMT+04:00 Phil Steitz <ph...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] git
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-07-05 19:54 GMT+04:00 Phil Steitz <ph...@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
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org