Bernd Schmidt <[EMAIL PROTECTED]> wrote: >>> One additional question, suppose I don't want to merge a huge number of >>> revisions in one go, and I do >>> svnmerge.py merge -r a-small-list-of-revisions >>> svn diff ;; to verify everything is OK >>> >>> Do I then have to commit the merge so far before running svnmerge.py >>> again, or can it get all the information it needs from the local >> >> repository? >> >> Also note that, theoretically, it's better to do it in one-go as you'd end >> up with less conflicts. > > Why is that - do you mean merge conflicts?
Yes. I'm speaking of the general case, of course. Think of two trunk commits modifying the same file at the same place: if you merge in one go, you'll end up with a single conflict. If you do more merge operations, the file might conflict twice, ending up with two sets of merge markers (and two set .rXXX files, ecc.). If you clean up after each merge, it's of course better, but you'll still have to clean up twice instead of once. But of course, it's up to you to decide what's the best for you branch. > I imagine that most of the revisions from trunk will just apply cleanly > since the files are unchanged on the branch. For changes in reload*.*, > I'd rather merge one revision at a time and make sure I update the > affected files properly (I very much doubt any large change will apply > cleanly in those files; they'll need manual intervention). I assume > it'll be easier to correct merge errors for every individual change > rather than trying to piece them together after a monster merge. I understand, and I reckon this is the best for your situation. svnmerge can handle range of changes as well as cherry-picking single changes, and will correctly keep track of everything. Let me know if it works out correctly. -- Giovanni Bajo
