You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2011/09/01 00:04:12 UTC
Re: svn commit: r1163802 - in /tomcat: tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
trunk/java/org/apache/catalina/loader/WebappClassLoader.java
On 31/08/2011 22:57, Konstantin Kolinko wrote:
> 2011/9/1 Mark Thomas <ma...@apache.org>:
>> On 31/08/2011 21:35, slaurent@apache.org wrote:
>>> Author: slaurent
>>> Date: Wed Aug 31 20:35:22 2011
>>> New Revision: 1163802
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1163802&view=rev
>>> Log:
>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51741
>>> bug 51741: Eclipse WTP "Serve modules without publishing" broken with tc7, needs patch in tomcat
>>
>> This should have been applied just to /trunk and then merged to 7.0.x/trunk.
>>
>
> This Sylvain's commit patches both trunk and 7.0.x at the same time.
> Thus there is no need to merge.
I know what the patch did. The point is that committing like this messes
with the mergeinfo. It may (or may not) cause us some headaches at some
point in the future. Given we don't have to commit trunk and 7.0.x/trunk
together, I'd rather we continued with the current practise of trunk
first and then merge.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1163802 - in /tomcat: tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Posted by Mark Thomas <ma...@apache.org>.
On 31/08/2011 23:34, Konstantin Kolinko wrote:
> We already did such updates to trunk+branch when working on 6.0.x and
> I prefer to keep this practice.
Committing to trunk and 7.0.x at the same time may also cause
complications if we want to merge the patch back to 6.0.x. 5.5.x is less
on an issue since the different structure almost always means a manual
merge any way.
I continue to think that the simplest way to handle this is as we have
been doing.
Commit to trunk
Merge trunk -> 7.0.x unless trunk specific
Merge trunk -> 6.0.x if required
Merge trunk -> 5.5.x if required (may be manual)
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1163802 - in /tomcat: tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Posted by Mark Thomas <ma...@apache.org>.
On 31/08/2011 23:34, Konstantin Kolinko wrote:
> Here is a list of modified files:
>> svn status
> [[[
> C .
> A + TOMCAT-NEXT.txt
> ? dir_conflicts.prej
> M build.xml
> X modules\jdbc-pool
> M build.properties.default
> M test\org\apache\coyote\ajp\TesterAjpMessage.java
> M test\org\apache\catalina\core\TestStandardContext.java
> M java\org\apache\coyote\http11\Http11Processor.java
> M java\org\apache\coyote\http11\Http11AprProtocol.java
> M java\org\apache\coyote\ajp\AjpAprProtocol.java
> M java\org\apache\coyote\ajp\AjpMessage.java
> M java\org\apache\jasper\JspCompilationContext.java
> M java\org\apache\tomcat\util\net\AprEndpoint.java
> M java\org\apache\catalina\Host.java
> M java\org\apache\catalina\startup\ContextConfig.java
> M java\org\apache\catalina\startup\ExpandWar.java
> M java\org\apache\catalina\startup\HostConfig.java
> M java\org\apache\catalina\core\StandardHost.java
> M java\org\apache\catalina\core\StandardContext.java
> M java\org\apache\catalina\ha\deploy\FarmWarDeployer.java
> M java\org\apache\catalina\manager\HTMLManagerServlet.java
> M java\org\apache\catalina\manager\ManagerServlet.java
> M res\maven\mvn.properties.default
> M res\ide-support\eclipse\stop-tomcat.launch
> M res\ide-support\eclipse\java-compiler-errors-warnings.txt
> M res\ide-support\eclipse\eclipse.project
> M res\ide-support\eclipse\start-tomcat.launch
> M webapps\docs\changelog.xml
> M RELEASE-NOTES
> M BUILDING.txt
I was surprised the list was so long so I looked into it. There were a
few minor typo fixes in trunk that hadn't made it to 7.0.x that I
back-ported. The rest were either version changes (expected) or the
Host.getAppBaseFile() change. I had forgotten how much duplication that
removed.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1163802 - in /tomcat: tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Posted by Sylvain Laurent <sy...@gmail.com>.
I'm using subclipse which contains a 1.6 svn client. I'm not an svn expert, I'll try to do as Mark recommends, I see the point of performing the merge after so that svn can keep track of things.
Sylvain
Le 1 sept. 2011 à 00:34, Konstantin Kolinko <kn...@gmail.com> a écrit :
> 2011/9/1 Mark Thomas <ma...@apache.org>:
>> On 31/08/2011 22:57, Konstantin Kolinko wrote:
>>> 2011/9/1 Mark Thomas <ma...@apache.org>:
>>>> On 31/08/2011 21:35, slaurent@apache.org wrote:
>>>>> Author: slaurent
>>>>> Date: Wed Aug 31 20:35:22 2011
>>>>> New Revision: 1163802
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1163802&view=rev
>>>>> Log:
>>>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51741
>>>>> bug 51741: Eclipse WTP "Serve modules without publishing" broken with tc7, needs patch in tomcat
>>>>
>>>> This should have been applied just to /trunk and then merged to 7.0.x/trunk.
>>>>
>>>
>>> This Sylvain's commit patches both trunk and 7.0.x at the same time.
>>> Thus there is no need to merge.
>>
>> I know what the patch did. The point is that committing like this messes
>> with the mergeinfo. It may (or may not) cause us some headaches at some
>> point in the future. Given we don't have to commit trunk and 7.0.x/trunk
>> together, I'd rather we continued with the current practise of trunk
>> first and then merge.
>
> I prefer this practice of updating trunk + 7.0.x at the same time for
> small patches, e.g. documentation.
>
> To check whether it causes problems or not:
> I did a merge of trunk to 7.0.x for revisions 1155369-HEAD,
> using svn 1.7 (a nightly of TortoiseSVN)
>
> I had to start the merge command twice, because of conflict in
> changelog.xml, and there was a conflict with subclipse:tags property,
> but in the end it completed successfully.
>
> Here is a list of modified files:
>> svn status
> [[[
> C .
> A + TOMCAT-NEXT.txt
> ? dir_conflicts.prej
> M build.xml
> X modules\jdbc-pool
> M build.properties.default
> M test\org\apache\coyote\ajp\TesterAjpMessage.java
> M test\org\apache\catalina\core\TestStandardContext.java
> M java\org\apache\coyote\http11\Http11Processor.java
> M java\org\apache\coyote\http11\Http11AprProtocol.java
> M java\org\apache\coyote\ajp\AjpAprProtocol.java
> M java\org\apache\coyote\ajp\AjpMessage.java
> M java\org\apache\jasper\JspCompilationContext.java
> M java\org\apache\tomcat\util\net\AprEndpoint.java
> M java\org\apache\catalina\Host.java
> M java\org\apache\catalina\startup\ContextConfig.java
> M java\org\apache\catalina\startup\ExpandWar.java
> M java\org\apache\catalina\startup\HostConfig.java
> M java\org\apache\catalina\core\StandardHost.java
> M java\org\apache\catalina\core\StandardContext.java
> M java\org\apache\catalina\ha\deploy\FarmWarDeployer.java
> M java\org\apache\catalina\manager\HTMLManagerServlet.java
> M java\org\apache\catalina\manager\ManagerServlet.java
> M res\maven\mvn.properties.default
> M res\ide-support\eclipse\stop-tomcat.launch
> M res\ide-support\eclipse\java-compiler-errors-warnings.txt
> M res\ide-support\eclipse\eclipse.project
> M res\ide-support\eclipse\start-tomcat.launch
> M webapps\docs\changelog.xml
> M RELEASE-NOTES
> M BUILDING.txt
>
> Performing status on external item at 'modules\jdbc-pool':
> Summary of conflicts:
> Property conflicts: 1
> ]]]
>
> ../loader/WebappClassLoader.java is not on the list and that means
> that this change has been successfully skipped (and that is what
> svn:mergeinfo is for).
>
> I think that such skipping is called "implicit mergeinfo".
> I cannot say how it would behave with 1.6 svn clients (I hope it
> works, but I heard that 1,7 has improvements). Svn 1.7 is rather near
> - the first release candidate was released today and release expected
> in a month (after the "soak" period).
>
> We already did such updates to trunk+branch when working on 6.0.x and
> I prefer to keep this practice.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1163802 - in /tomcat: tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/9/1 Mark Thomas <ma...@apache.org>:
> On 31/08/2011 22:57, Konstantin Kolinko wrote:
>> 2011/9/1 Mark Thomas <ma...@apache.org>:
>>> On 31/08/2011 21:35, slaurent@apache.org wrote:
>>>> Author: slaurent
>>>> Date: Wed Aug 31 20:35:22 2011
>>>> New Revision: 1163802
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1163802&view=rev
>>>> Log:
>>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=51741
>>>> bug 51741: Eclipse WTP "Serve modules without publishing" broken with tc7, needs patch in tomcat
>>>
>>> This should have been applied just to /trunk and then merged to 7.0.x/trunk.
>>>
>>
>> This Sylvain's commit patches both trunk and 7.0.x at the same time.
>> Thus there is no need to merge.
>
> I know what the patch did. The point is that committing like this messes
> with the mergeinfo. It may (or may not) cause us some headaches at some
> point in the future. Given we don't have to commit trunk and 7.0.x/trunk
> together, I'd rather we continued with the current practise of trunk
> first and then merge.
I prefer this practice of updating trunk + 7.0.x at the same time for
small patches, e.g. documentation.
To check whether it causes problems or not:
I did a merge of trunk to 7.0.x for revisions 1155369-HEAD,
using svn 1.7 (a nightly of TortoiseSVN)
I had to start the merge command twice, because of conflict in
changelog.xml, and there was a conflict with subclipse:tags property,
but in the end it completed successfully.
Here is a list of modified files:
> svn status
[[[
C .
A + TOMCAT-NEXT.txt
? dir_conflicts.prej
M build.xml
X modules\jdbc-pool
M build.properties.default
M test\org\apache\coyote\ajp\TesterAjpMessage.java
M test\org\apache\catalina\core\TestStandardContext.java
M java\org\apache\coyote\http11\Http11Processor.java
M java\org\apache\coyote\http11\Http11AprProtocol.java
M java\org\apache\coyote\ajp\AjpAprProtocol.java
M java\org\apache\coyote\ajp\AjpMessage.java
M java\org\apache\jasper\JspCompilationContext.java
M java\org\apache\tomcat\util\net\AprEndpoint.java
M java\org\apache\catalina\Host.java
M java\org\apache\catalina\startup\ContextConfig.java
M java\org\apache\catalina\startup\ExpandWar.java
M java\org\apache\catalina\startup\HostConfig.java
M java\org\apache\catalina\core\StandardHost.java
M java\org\apache\catalina\core\StandardContext.java
M java\org\apache\catalina\ha\deploy\FarmWarDeployer.java
M java\org\apache\catalina\manager\HTMLManagerServlet.java
M java\org\apache\catalina\manager\ManagerServlet.java
M res\maven\mvn.properties.default
M res\ide-support\eclipse\stop-tomcat.launch
M res\ide-support\eclipse\java-compiler-errors-warnings.txt
M res\ide-support\eclipse\eclipse.project
M res\ide-support\eclipse\start-tomcat.launch
M webapps\docs\changelog.xml
M RELEASE-NOTES
M BUILDING.txt
Performing status on external item at 'modules\jdbc-pool':
Summary of conflicts:
Property conflicts: 1
]]]
../loader/WebappClassLoader.java is not on the list and that means
that this change has been successfully skipped (and that is what
svn:mergeinfo is for).
I think that such skipping is called "implicit mergeinfo".
I cannot say how it would behave with 1.6 svn clients (I hope it
works, but I heard that 1,7 has improvements). Svn 1.7 is rather near
- the first release candidate was released today and release expected
in a month (after the "soak" period).
We already did such updates to trunk+branch when working on 6.0.x and
I prefer to keep this practice.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org