On Sat, Sep 7, 2013 at 4:25 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_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_at_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
Received on 2013-09-07 12:41:55 CEST