2012/6/6 Christopher Schultz <ch...@christopherschultz.net>: > Konstantin, > > On 6/6/12 8:52 AM, kkoli...@apache.org wrote: >> Author: kkolinko >> Date: Wed Jun 6 12:52:20 2012 >> New Revision: 1346864 >> >> URL: http://svn.apache.org/viewvc?rev=1346864&view=rev >> Log: >> Remove svn:merge-info property on EchoMessage.java, that was added in >> r1346684 >> >> Note: Merges should be started from project root - tc7.0.x/trunk, and >> project root has >> to be included in subsequent commit. That way svn:merge-info will be present >> only on the project root directory. > > Sorry about that. I use Eclipse: what is the best way to do and commit a > proper merge? Should I be committing not only the changed files but also > the project-root as a directory? If I do that, I think Eclipse (or even > svn) would force me to commit every change all at once -- i.e. I can't > work on multiple patches at the same time. > > I'm sure that's not true, so I'm certainly open to some education. >
I am using TortoiseSVN and svn command line client (both version 1.7). I do not know Eclipse SVN GUI, but the recommendations below are generic ones. I would recommend the following: # Merging: 1. Run "update" before merge. Check for uncommitted changes. Both should make the merge run faster and be more smooth. 2. Invoke merge from the root of the project, so that svn:merge-info on the project root directory is updated. Otherwise svn:mergeinfo will be set on the node where you started the merge from. # Reverting after a merge: If you need to revert after a merge (e.g. to rerun it), you should revert the root of the project, so that svn:mergeinfo property change on it is reverted. # Committing after a merge: 1. Start commit from the root of the project. This is so that svn:mergeinfo property change on that directory is committed as well. (I revert all local changes from 6.0.x or 7.0.x branch before merging a backport there, so I do not have the need to exclude some files from commit.) The internal API, I think, allows to distinguish recursive commits and non-recursive ones. Command line has --depth argument to many svn commands, but I do not know how well the GUI works in your case. When in doubt, it is better to prioritize the actual changes over mergeinfo management. This "start from root" recommendation is needed after a merge only and only to commit mergeinfo update. E.g. - it is not needed on trunk where most development takes place, - it is not needed if you ported the change manually (though you can run a "record-only" merge if you want to mark original revision as merged) "svn merge --record-only" - If you ported only a part of the original change, do not commit mergeinfo update, because it will prevent from rerunning the merge. Revert property change on the root directory (after committing the rest). 2. I usually review the diff before committing. TortoiseSVN has "Show changes as unified diff" command. Command-line has "svn diff" command. Eclipse probably has something like that. I hope this will be useful. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
