If you always sync a feature branch before you merge it back, why do you really have to use the --reintegrate option?
The Subversion book says:
When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmosh of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)
So the --reintegrate option only merges the changes that are unique to the feature branch. But if you always sync before merge (which is a recommended practice, in order to deal with any conflicts on the feature branch), then the only changes between the branches are the changes that are unique to the feature branch, right? And if Subversion tries to merge code that is already on the target branch, it will just do nothing, right?
In this blog post, Mark Phippard writes:
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
If we include those synched revisions, then we merge back changes that already exist in trunk. This yields unnecessary and confusing conflicts.
Can somebody give me an example of when dropping reintegrate gives me unnecessary conflicts?
