[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: Stephen Butler <sbutler_at_elego.de>
Date: Fri, 16 Mar 2012 15:50:18 +0100

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.

Received on 2012-03-16 15:50:54 CET

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