gstein_at_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_at_N to B; mv C_at_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
>
>
Received on 2013-06-26 00:40:20 CEST