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" <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.
>
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
Received on 2012-03-16 15:50:54 CET