On Mar 16, 2012, at 15:31 , Greg Stein wrote: > 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. > I thought Subversion was generally neutral about semantics, except when the user sets various svn:* properties. > The name is an intrinsic part of a file's semantics. > A java package name is also meaningful, but I might change it in my working copy, and expect that my colleagues' changes will be applied to the new name automatically. > >... > > 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. > Some people switching from ClearCase to Subversion are annoyed that any change during update is made without consulting them each time. We force them to trust diff3. > >... > > 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 > Strawman? It's the reality for users since 1.6 came out. You don't have to take the blame for it, and I won't take _all_ the blame for it, but resolving tree conflicts is still a lot of tedious work in 1.7. Sort of like tracking merges in 1.4. > 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 >
Some users do want more control over update (i.e., they trust Subversion less). Interactive resolution during or after update is an interesting scenario. Steve
