gst...@apache.org wrote on Wed, Jan 25, 2012 at 14:45:02 -0000: > Author: gstein > Date: Wed Jan 25 14:45:01 2012 > New Revision: 1235773 > > URL: http://svn.apache.org/viewvc?rev=1235773&view=rev > Log: > Add some clarifications to the Ev2 documentation, based on some IRC > discussions with danielsh. > > * subversion/include/svn_editor.h: > (...): add a section on "Timing and State" to clarify how the > editing calls refer to the receiver's current state. provide a > couple examples. > > Modified: > subversion/trunk/subversion/include/svn_editor.h > > Modified: subversion/trunk/subversion/include/svn_editor.h > URL: > http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_editor.h?rev=1235773&r1=1235772&r2=1235773&view=diff > ============================================================================== > --- subversion/trunk/subversion/include/svn_editor.h (original) > +++ subversion/trunk/subversion/include/svn_editor.h Wed Jan 25 14:45:01 2012 > @@ -329,6 +329,19 @@ extern "C" { > * for these items are invoked. > * \n\n > * > + * <h3>Timing and State</h3> > + * The calls made by the driver to alter the state in the receiver are > + * based on the receiver's *current* state, which includes all prior changes > + * made during the edit. > + *
Should we change this to say: + * <h3>Timing and State</h3> + * The calls made by the driver to alter the state in the receiver are + * based on the receiver's *initial* state, which excludes all prior changes + * made during the edit. ? I've reviewed the IRC logs referred to in the log msg [1], as well as today's, and I don't see a good reason to stick with the "refers to current state"; and I do see a good reason to use "refers to initial state": that's closer to the final copyfrom (or moved-from) info. I also find "refers to the initial state" more intuitive. Daniel [1] http://colabti.org/irclogger/irclogger_log/svn-dev?date=2012-01-25 [2] http://colabti.org/irclogger/irclogger_log/svn-dev?date=2013-06-26 > + * Example: copy A to B; set-props on A; copy A to C. The props on C > + * should reflect the updated properties of A. > + * > + * Example: mv A@N to B; mv C@M to A. The second move cannot be marked as > + * a "replacing" move since it is not replacing A. The node at A was moved > + * away. The second operation is simply moving C to the now-empty path > + * known as A. > + * > * <h3>Paths</h3> > * Each driver/receiver implementation of this editor interface must > * establish the expected root path for the paths sent and received via the > >
