[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Updating local-moves (was: svn commit: r1301390 ...)

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 16 Mar 2012 10:31:36 -0400

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.