On Fri, Sep 6, 2013 at 11:36 AM, Branko Čibej <brane_at_wandisco.com> wrote:
> On 06.09.2013 17:50, Philip Martin wrote:
>> Philip Martin <philip.martin_at_wandisco.com> writes:
>...
>> I've been thinking about alter_dir and I see no reason, in the update
>> editor at least, for a rule that requires alter_dir before adding or
>> removing children. The Ev2 "once" rule is designed to ensure that Ev2
>> actions can be applied to the nodes in the working copy as the actions
>> are received and that the working copy nodes will always reflect
>> repository nodes. This doesn't require alter_dir on the parent before
>> add/delete of children.
>
> Actually, the Once Rule is way more important for server implementations
> than client implementations. It effectively defines when the server can
> commit changes to a node and assume no further changes will happen
> later.
Yes.
In conversations with Jon Trowbridge a few years back, he described
the trouble Google had with a rewrite of their svn/BigTable backend
because they couldn't determine when a node was "done".
A secondary driver for the Once Rule is an atomic change for a
directory so that it doesn't remain in the "incomplete" state during
an update (and this was carried into wc_db.h). Instead, the *children*
are marked incomplete, pending future node actions. The directory
itself is modified and "done" in a single operation.
The notion of single, atomic operations is a huge design point of Ev2.
This is why I'm *extremely* leery of the dual entry points (and
unknown duration!) for performing a move. I have yet to see a
description of where/how source-initial-state and a single move
operation breaks down.
>...
To Philip's point: it does seem quite reasonable to allow child
changes before an alter_dir(). I could have a directory at r10, and a
(new) child at r11. That is allowed and logical. Thus, an editor drive
could move a child to r11 before it moves the parent to r11 (which
specifies that child).
Cheers,
-g
Received on 2013-09-06 19:36:51 CEST