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