Re: Merge bug causes changesets to be applied although this should not be the case
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 11 Apr 2013 20:59:56 +0100 (BST)
Christoph Schulz wrote:
> [...] the problem is that [...] no conflict is _detected_ at all.
I agree that this behaviour is not good when you want strict conflict detection.
This particular behaviour is just one of several heuristics in Subversion that aim to help the more casual user by producing a 'fairly obvious' output instead of being strict and flagging a conflict. These heuristics include:
* If the target file content is already equal to the right-hand side of the merge source, then do nothing. (That's this issue.)
* When adding a whole
* In some cases, deleting a file that is already deleted is not considered a conflict.
And there are probably more.
> Stefan Sperling wrote:
Users have different needs when merging. Some people merge in a loosely controlled setting, where the same change may have been made on two different branches independently, or patches may have been applied that haven't been recorded as merges, and so on. In that kind of situation it can be most useful if the tool automatically chooses a reasonably likely result for each conflict.
On the other hand, sometimes people merge in a tightly controlled setting, where perhaps each change entered the version control system on exactly one branch, and the mergeinfo accurately reflects what has and has not been merged, and so on. The user expects the merge to apply a predictable set of changes. The user may know that none of the changes are going to conflict unless the user has made a mistake, or perhaps the user knows that the only changes that might conflict are the changes that touch a certain set of files. In this kind of situation, it is helpful if the tool can flag any unexpected situation, because quite likely a mistake has been made.
Of course in 'strict' mode it will be useful for Subversion to offer an easy way for the user to select the 'obvious' resolution for the conflict, but the more important thing is to be able to detect such conflicts.
So I would like us to implement such a mode.
(I have been thinking of the 'strict mode' for a couple of years already, but I still don't know the complete list of heuristics that we have at the moment. I only became aware of this "don't merge if the file already looks like the right-hand side of the incoming change" heuristic a few weeks ago when I was digging through that part of the code.)
The simplest implementation would have a single mode flag that just selects 'strict' or 'not strict'. A slightly more sophisticated implementation could have a bunch of flags that individually control the various heuristics, and probably a top-level control to easily switch them all on or all off. Either way, this would be a significant improvement.
This is an archived mail posted to the Subversion Dev mailing list.