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.
Received on 2012-03-16 15:04:00 CET