Greg Stein <gstein_at_gmail.com> writes:
> On Mar 16, 2012 9:29 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
>>
>> 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",
Yes.
> 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.
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. 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. We might put an extra call into
open_file or close_file to break the recorded move and then let the
update continue.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2012-03-16 16:28:44 CET