Commands for correctly merging to the python 3.0 maintenance branch
Getting the svnmerge-intergrated property right when merging trunk->py3k->release30 is a little tricky. The most concise set of instructions I have found which gets it right is to do the following in the 3.0 maintenance branch after committing to the py3k branch: svn update svnmerge merge -r <py3k-rev> svn revert . svnmerge -M -F <py3k-rev> <test change still works, etc> svn commit -F svnmerge-commit-message.txt Revert and property changes on "." and running that second svnmerge line is also useful if you do a "svn update" after the first svnmerge and get a conflict on the svnmerge-intregrated property. The -M option tells the utility to only make the property changes, while the -F tells it to go ahead despite the existence of local modification. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Martin v. Löwis wrote:
svn revert . svnmerge -M -F <py3k-rev>
[are you sure you don't need a command for svnmerge here?]
D'oh, I thought I fixed that before sending the message. Yes, that line should indeed be: svnmerge merge -M -F <py3k-rev>
Instead of these two, I always do
svn resolved .
That's what I had been doing before today, and I believe it works correctly so long as you never get the svn update and svnmerge merge operations out of sequence (i.e. always update and only then merge). However, I encountered the case today where I had already merged to the maintenance branch and did the svn update afterwards. In that situation, reverting the property changes and reapplying them was the only way for me to avoid losing the record of the changes everyone else had already merged. If I hadn't checked the property diff and noticed that several merged revisions were no longer listed in the property in my working copy, then svnmerge may have become very confused. The revert+redo-merge-bookkeeping approach is definitely slower than just marking the conflict as resolved, but has a definite advantage in doing the right thing even if the earlier update+merge operations were performed out of sequence (or if an extra update becomes necessary due to checkins after the merge was performed). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (2)
-
"Martin v. Löwis" -
Nick Coghlan