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