On Sat, Sep 7, 2013 at 4:25 AM, Philip Martin <philip.mar...@wandisco.com> wrote: > Greg Stein <gst...@gmail.com> writes: > >> On Fri, Sep 6, 2013 at 1:47 PM, Philip Martin >>> Two people at least. I have shown how Ev2 with a split move could >>> handle the case >>> >>> A/B/C to A >>> A/B to A/B >>> A to A/B/C >>> >>> What is your alternative? > > How does you suggestion work? Start with > > NODES local_relpath revision status repos_path
You asked me how the API would work. "The NODES table doesn't support it" is not a response. Further: why would moves even be reported to the client? Moves are operations for the *repository* to remember. The client could care less, and Branko also pointed out the difficulty of trying to do moves within a mixed-revision working copy. "But. But. Are you saying that Ev2 can't be applied uniformly everywhere? That we can't move() a working copy?" .. Yeah. So what. We need to describe certain transformations. That process can and should be *similar* so that experience with one, can be carried to the next. It doesn't mean absolutism. Every driver knows every receiver. Or if you don't like that coupling, then just say every driver knows the tree state of every receiver and knows that trying to drive moves in a mix-rev receiver is gonna monkey stuff up fast. >... >> move(A/B/C@original, A, replace=R) > > What does the receiver do? I suppose it could implement the replace and > move the replaced nodes to some temporary table: We discussed this already. The receiver needs to retain the original state. We even suggested a variant parameter to say "hey. you likely need to retain the original state, so go do some extra work." So yes, there is some work in wc.db. >... >> Not sure of the intent with children (ie. what is retained under A/B/C). > > What children? Every node gets moved. Fine. Was just asking, if there were any further thoughts re: children. >... Cheers, -g
