[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

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 16 Mar 2012 12:28:05 -0400

On Mar 16, 2012 11:28 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>...
> > then the update to A/f_at_4 is a
> > conflict. Today, we call it an incoming-edit/local-delete conflict. With
> > moves, this is what I've been saying: it becomes an
> > incoming-edit/local-move conflict. It doesn't mysteriously and silently
> > update B/f.
> >
> > The user can choose two outcomes, I believe:
> > 1) apply edit to B/f. Local-move becomes A/f_at_4 to B/f.
> > 2) install A/f_at_4. Local-move becomes copy of A/f_at_3 to B/f.
>
> In both cases the base node for A/f is updated from 3 to 4.

Agreed.

As I just replied to Julian, I believe an 'svn update' should always
make BASE reflect the repository. Local-mods are simply rewritten in
terms of the new BASE, possibly recording conflicts in that process.

> To keep the database in a valid state we must either update the moved
> node B/f to 4 as well, or break the move.

Agreed.

In my note to Julian, I suggested that we update B/f to be a move from
A/f_at_4 (and then reapply any local-mods). That would become the
"default" resolution, which matches Stefan's preference. Conflict
resolution could convert it into a copy of A/f_at_3 and restore A/f_at_4.

> Whether we do it
> automatically or let the user choose isn't what concerns me at the
> moment.  What I want to achieve is a database that remains in a valid
> state.  Once we have the database moving from one valid state to another
> it is relatively easy to tweak the UI.

Agreed!

Cheers,
-g
Received on 2012-03-16 17:28:37 CET

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