Unfortunately, I haven't started to examine these aspects of the WC.
My efforts have focused around the management of the pristine files,
and the read/write access of them. The whole "scheduling" stuff is
pretty archaic and very touchy. I totally believe there are different
pieces of code with different interpretations :-(
On Tue, Dec 9, 2008 at 08:10, Julian Foad <julianfoad_at_btopenworld.com> wrote:
>...
> +++ subversion/include/svn_wc.h (working copy)
> @@ -1985,6 +1985,7 @@ typedef struct svn_wc_entry_t
> /** in a copied state (possibly because the entry is a child of a
> * path that is @c svn_wc_schedule_add or @c svn_wc_schedule_replace,
> * when the entry itself is @c svn_wc_schedule_normal) */
> + /** ### How is this related to (copyfrom_url != NULL)? */
> svn_boolean_t copied;
Hmm. Maybe we set copied on all the children, but do not generate a
copyfrom_url? Haven't done the research to know.
>...
> -/* Our general purpose intelligence module for handling scheduling
> - changes to a single entry.
> +/* Our general purpose intelligence module for handling a scheduling
> + change to a single entry.
> + ### Determine the entry's new schedule, assuming both the base and the
> + working version are being changed in the way indicated by the incoming
> + "schedule".
> + ### Determine the entry's new schedule, assuming the base is unchanged
> + and the working version is being changed in the way indicated by the incoming "schedule".
The schedule state always represents the WORKING version. "normal"
means it matches BASE -- that it has no (structural) changes pending.
>...
> @@ -2740,6 +2748,8 @@ fold_scheduling(apr_hash_t *entries,
> case svn_wc_schedule_add:
> case svn_wc_schedule_replace:
> /* These are all no-op cases. Normal is obvious, as is add.
> + ### The 'add' case is not obvious: above, we throw an error if
> + ### already versioned, so why not here too?
No idea. The state change stuff here doesn't make a lot of sense to
me. It would be more obvious if the change was described explicitly as
intent, rather than implied by from/to states (which could get revised
anyways!).
>...
> + "Folding in" a change means, in most cases, simply replacing the field
> + with the new value. However, for the "schedule" field, unless
> + MODIFY_FLAGS includes SVN_WC__ENTRY_MODIFY_FORCE (in which case just take
> + the new schedule from ENTRY), it means to determine the schedule that the
> + entry should end up with if the "schedule" value from ENTRY represents a
> + change/add/delete/replace being made to the
> + ### base / working / base and working version(s) ?
> + of the node.
Always WORKING.
>...
> - /* Non-null if this is a 'switch' operation. */
> + /* The target URL of ###(what level of) the switch, if this is a 'switch'
> + operation, else NULL. */
> const char *switch_url;
Hunh? I don't understand the question. (not that I really know that
field anyways :-P )
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981925
Received on 2008-12-10 00:55:38 CET