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" <s...@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
