On Fri, Sep 6, 2013 at 11:36 AM, Branko Čibej <br...@wandisco.com> wrote: > On 06.09.2013 17:50, Philip Martin wrote: >> Philip Martin <philip.mar...@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
