I'm trimming hard on this reply because you've identified a core/key
principle that we differ on. And from there, everything else falls out from
there.
On Mar 16, 2012 10:03 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:
>...
> > 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.
And that's where I say you're wrong :-)
$ svn mv foo.conf foo.conf.base
$ edit foo.conf.base # remove local conf
$ edit foo.conf # include base. local override.
$ svn add foo.conf
Any incoming edits should not be applied to .base automatically. I changed
the semantics of that file through its rename.
The name is an intrinsic part of a file's semantics.
>...
> 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.
Exactly. We already agreed there are two intentions present. A query to
resolve them seems prudent, and I maintain it seems required.
>...
> 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.
Back to a strawman. I never suggested created this difficulty.
Let's focus on flagging a conflict, where one possible resolution is
applying the edits to the move-dst. Through interactive resolution, or
possibly with a sweeping command along the lines of:
$ svn resolve . -R --accept=apply-to-moves
>...
Cheers,
-g
Received on 2012-03-16 15:32:09 CET