On Fri, Mar 16, 2012 at 08:47:43AM -0400, Greg Stein wrote: > Don't tell me my use case is wrong. I described it, and that is what you > now should work with. > > I thought the code didn't work at A. I wanted features X+Y at B rather than > A. So I move it. > > Somebody else thought A should not implement Y. > > That is a conflict. Two different intentions.
Yes, it is. We agree on that. This is definitely a conflict of intentions. > And I believe a tree conflict. I don't agree here. For sake of argument, let's simplify your example and take out the move: I thought the code didn't work in A. I wanted features X+Y at A instead. So I change it. Somebody else thought A should not implement Y. What happens in that case? I will get an automatic merge, and if I'm lucky I will also get a text conflict from diff3. If I'm unlucky I get a semantic conflict that not even the compiler or regression tests will catch. By your logic, the above example suddenly changes into a hard conflict scenario just because the name of a container has changed. From my point of view that's inconsistent. Any incoming change during an update can be a conflict of intentions. Do we always mark a conflict because of that? No we don't. We've already accepted that some kinds of conflicts cannot be caught unless sufficient testing and review is happening. > I could just as well argue prop changes, and other more explicit > changes within this overall move (eg. maybe I remove Y and an associated > config file, yet the other guy adds Z that should not be in the code at > path B). > > These should be tree conflicts, rather than silent application of edits to > moved nodes. This really boils down to the question of what a "move" really means. You seem to regard a move as something that is a semantic change for its own sake. I don't. I say a move just changes the name of a thing, and it's still the same thing with the same content and meaning within the context of my project and the changes I make. Other people are still using the old name for this thing because I haven't committed the move yet, but the changes they make affect the same thing. Also, I don't agree that changes are applied silently. The update clearly shows that it's touching the file, and 'svn diff' also displays different changes after the update. And there might even be a text conflict flagged. Of course, svn could ask, every time: "Do you want me to apply the text edits over there? (yes/no) " I could probably live with that. But the prompt doesn't really help a whole lot. It's primary function is to alert the user. Assuming the user says "yes", does it always produce good results? Of course it won't. Just like a normal 'svn update' even without renames involved doesn't always produce good results. I would like svn to seamlessly update/merge text edits on top of local renames. That behaviour makes sense to me. I want either automatic merges that I can then review, or text conflicts where diff3 will flag them. Right now, we don't auto-merge the changes, and manually merging them in case they are wanted is a huge hassle. You need to figure out the correct diff to merge first, then run 'svn merge' on the file, or apply the edits manually -- tasks that 'svn' could already have performed on the user's behalf. These manual steps take a lot of time away from users. Especially if they aren't very comfortable with running a merge. Many people just know how to use commit/update and get along fine until they run into a conflict like this. I expect users will most of the time be happy to just have the changes applied at the new location automatically and then reason about whether the changes made to the file's content make sense. > And don't tell me to use copy as a user strategy to avoid future changes > and conflicts. Well, a tool is a tool, and sometimes a newer model has the red button at a different spot. We're discussing a question about the expected semantics of 'svn move' which has always had copy+delete semantics because it was implemented like that. But that's now changing and I argue that this change is an improvement. You can still have the semantics you're asking for without any significant hoops to jump through. It's not like we were taking any functionality away by making this change.
