Konstantin, On 6/6/12 2:45 PM, Konstantin Kolinko wrote: > # Merging: > > 1. Run "update" before merge.
Of course :) > 2. Invoke merge from the root of the project, so that svn:merge-info > on the project root directory is updated. I think this is what I failed to do with the EchoServlet: since there was only a single file changed, I did the merge on that file only. > 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. Good to know. > # 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. Gotcha. I checked, and using '--depth empty' will allow me to specify exactly which files to commit (including '.' at the project root) without svn performing any kind of recursion. So, I can work on multiple things at once as long as I only do a single merge at a time. > Command line has --depth argument to many svn > commands, but I do not know how well the GUI works in your case. I used the CLI with --depth first to ensure it did what I wanted. I'll see what Eclipse can do for me, now. > 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. Thanks. > 2. I usually review the diff before committing. Always. > TortoiseSVN has "Show changes as unified diff" command. > Command-line has "svn diff" command. > Eclipse probably has something like that. It does: you can compare the working copy (or a selection of files) against HEAD. Eclipse also helpfully gives you a quick-diff along with the list of files that have changed in the "commit message" dialog so you can record the commit message and browse the changes simultaneously. Thanks a lot, -chris
signature.asc
Description: OpenPGP digital signature
