Greg Stein <gst...@gmail.com> writes: > On Mar 16, 2012 9:29 AM, "Philip Martin" <philip.mar...@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@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@3 to B/f",
Yes. > 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. 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
