Hi Christoph. Christoph Schulz wrote: > [...] silently ignoring the deletion of a non-existing file part is not a > sound decision in my opinion.
> [...] 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 text hunk, if the same hunk appears already at the same place (or at a similar place, as determined by the context-matching rules) then do nothing with that hunk. * When adding a whole file or directory, if that file already exists (even if its content is different) then there is an internal option to not flag a conflict. (The 'adds_as_modification' parameter to svn_client_update4(), which the svn command-line client sets true during 'svn update'.) * In some cases, deleting a file that is already deleted is not considered a conflict. And there are probably more. In my opinion, the user need to be able to specify either 'strict' mode or 'guess what I probably want' mode, since both modes are useful in different situations. The 'strict' mode should disable *all* of those heuristics and cause a conflict to be raised in those cases. > Stefan Sperling wrote: >> If we are currently giving our users less choice during conflict >> resolution than they should have, we need to fix that. If however >> there is only one practical resolution for the conflict in question, >> then I don't see a need to change Subversion's behaviour. 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. - Julian
