On Mar 16, 2012 11:28 AM, "Philip Martin" <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: >... > > then the update to A/f@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@4 to B/f. > > 2) install A/f@4. Local-move becomes copy of A/f@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@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@3 and restore A/f@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
