[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 11:04:30 -0400

On Mar 16, 2012 10:50 AM, "Stephen Butler" <sbutler_at_elego.de> wrote:
> On Mar 16, 2012, at 15:31 , Greg Stein wrote:
>...
>> On Mar 16, 2012 10:03 AM, "Stefan Sperling" <stsp_at_elego.de> wrote:
>...
>> > 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.

I've never suggested making users run 'svn merge' in this edit/move
conflict scenario. The resolution process does that.

I just think a conflict should be recorded. We should not make assumptions
when an ambiguity arrives. I've posited two possible resolutions for an
edit/move conflict. Philip has posited even more outcomes. Version control
must be as deterministic as possible. Heuristics(*) are, by definition,
non-deterministic.

>...

Cheers,
-g

(*) and we can skip the arguments about diff3 applying heuristics; that
bridge was crossed long ago, and don't we allow a replaceable tool if the
user doesn't like our heuristics?; how would a user replace our heuristic
of apply-to-dest unless we raise a conflict?
Received on 2012-03-16 16:05:02 CET

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