Re: Move using initial state (was: Update of "MoveDev/Ev2MovesDesign" ...)

On Sat, Sep 7, 2013 at 6:30 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 07.09.2013 12:47, Greg Stein wrote:
>...
>> I'm curious why a move() would be sent to a client.
>
> Off the top of my head:
>
> * It would help find better solutions to a category of tree conflicts
> that we currently do not handle very well.

Hmm. Yeah, I could see this. A local-edit could (easily) be re-applied
to an incoming-move.

> * It allows the client to optimize working copy changes, issueing
> filesystem-level moves of files and directories instead of rewriting
> and deleting them. In large working copies, a rename of a directory
> can be very expensive in the current copy+delete implementation.

Dunno about this. But it isn't really here/there. There is a lot of
work in between :-)

> But I'm astounded that you'd even consider having an asymmetric editor
> API. After all, it's not constrained to client<->server communication.

Nope. Just being pragmatic. The server is never mixed-rev. The client
is. You've been making that abundantly clear, and I think a reasonable
answer is constraint.

> It seems obvious to me in hindsight that Ev2 was designed mostly with
> the client->server direction in mind, and kind of ignored the issues on
> the working-copy side.

Look at the notes. And my emails. It was designed for atomicity, for
random-access, and to move away from a bare vtable. I could probably
list others. Whatever.

Ev1 is stone age. Ev2 is industrial age. If you think we can make a
further jump... fine.

It didn't ignore "issues". It simply tries to make a positive move
forwards. Was wc-ng perfect? FSX? Ev2? ... nope.

With that in mind, I suggested that a move() to the client isn't an
appropriate operation. It is *way* too complex. We have a hojillion
other problems that can be solved Right Now.

>...
> But high-level features such as mixed-revision working
> copies, switched subtrees, sparse trees etc. do have a non-trivial impact.

Yeah. That crap scares me :-)

But I return to: can we make forward progress without painting
ourselves into a corner? Can we *also* do that without analysis
paralysis? Can we solve the 90%? (without waiting for the 100%?)

Cheers,
-g
Received on 2013-09-07 13:56:51 CEST