On Tue, 2008-12-09 at 15:55 -0800, Greg Stein wrote:
> 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.
As discussed on IRC, I'm not completely sure about that in the context
of the way this argument is uinterpreted by the fold_schedule()
function.
> >...
> > - /* 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 )
I meant, does the subdirectory level of this field correspond to ANCHOR
or to ANCHOR+TARGET or to something else?
I have committed in r34639 this set of additions and questions, slightly
updated since the version in the email.
Thanks for your help.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=982154
Received on 2008-12-10 12:58:11 CET