[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Branko Čibej <brane_at_wandisco.com>
Date: Sat, 07 Sep 2013 13:30:32 +0200

On 07.09.2013 12:47, Greg Stein wrote:
> On Thu, Sep 5, 2013 at 6:51 AM, Branko Čibej <brane_at_wandisco.com> wrote:
>> ...
>> For the server->client-mixed-revision
>> scenario, I now believe this is not the case.
> 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.
  * 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.

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

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. I don't mean implementation details such as the
NODES table; those can't be used as valid arguments for defining API
semantics. But high-level features such as mixed-revision working
copies, switched subtrees, sparse trees etc. do have a non-trivial impact.

-- Brane

Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-09-07 13:31:14 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.