[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 10:11:40 -0400

On Mar 16, 2012 9:29 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
>
> Greg Stein <gstein_at_gmail.com> writes:
>
> > I think the update should ask, "apply edits to A/f to your moved B/f?".
>
> If the user says "no" then I think we would have to break the move and
> convert it into a copy + delete. If the user copies A/f_at_3 to B/f and
> then updates A/f to r4, it doesn't make sense for B/f to remain a move.

I think you misstated something here. "copies to" vs "remain a move".

If the first was "move A/f_at_3 to B/f", 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.

If the move-source is a directory, then the restore+changes becomes a bit
more difficult: how much to restore? For example, if I move A, an incoming
edit changes A/B/f, do I restore all of A (eg. A/C, A/D...) or just A/B?

> Note that the destination isn't always a working file. Consider a
> working copy with 3 files A/Y/f, B/Y/f, C/Y/f. Move A to X, delete X/Y,
> move B/Y to X/Y, delete X/Y/f, move C/Y/f to X/Y/f:
>
> op-depth local-relpath presence moved-to moved-here
> 0 A normal
> 0 A/Y normal
> 0 A/Y/f normal
> 1 A deleted X
> 1 A/Y deleted
> 1 A/Y/f deleted
> 0 B normal
> 0 B/Y normal
> 0 B/Y/f normal
> 2 B/Y deleted X/Y
> 2 B/Y/f deleted
> 0 C normal
> 0 C/Y normal
> 0 C/Y/f normal
> 3 C/Y/f deleted X/Y/f
> 1 X normal 1
> 1 X/Y normal 1
> 1 X/Y/f normal 1
> 2 X/Y normal 1
> 2 X/Y/f normal 1
> 3 X/Y/f normal 1
>
> So the file X/Y/f exists at op-depth 1, 2 and 3. An update that changes
> B/Y/f needs to update the row X/Y/f at op-depth 2 although no change is
> made to the working file.

Woah. Interesting!

Though I'd call that a conflict again. It is definitely an edit/delete
conflict (X/Y/f was explicitly deleted). I argue it is an edit/move
conflict first. If the user forward-applies the edit, they get the
edit/delete conflict. Though I guess a better phrase is edit/replace. What
are the resolution options for edit/replace? Toss the edit, or undo the
replace (a move-dest in this case) and apply the edit.

Cheers,
-g
Received on 2012-03-16 15:12:13 CET

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