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, slaur...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
