On Thu, Apr 11, 2013 at 9:59 PM, Julian Foad <julianf...@btopenworld.com> wrote: > 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
FYI, another user complained about this on the users list (Fredrik Orderud, CC'd) [1]. He has filed issue #4405 [2]. Perhaps some of the interested parties here can take a closer look? Or maybe Fredrik or anyone can start / continue discussion to go towards a detailed specification of the behavior of such an optional 'strict' flag or something like that ... (no specific interest myself, just trying to tie some loose ends together) [1] http://mail-archives.apache.org/mod_mbox/subversion-users/201308.mbox/%3ccahgmiisrngb1sogdlhkky+9epunqvjz8v7j_lyfakxezz54...@mail.gmail.com%3E [2] http://subversion.tigris.org/issues/show_bug.cgi?id=4405 (Merge order affects final result for repeated added & deleted changes) -- Johan
