tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Laurent <sylvain.laur...@gmail.com>
Subject 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
Date Thu, 01 Sep 2011 05:05:10 GMT
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 <knst.kolinko@gmail.com> a écrit :

> 2011/9/1 Mark Thomas <markt@apache.org>:
>> On 31/08/2011 22:57, Konstantin Kolinko wrote:
>>> 2011/9/1 Mark Thomas <markt@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


Mime
View raw message