We'd like to move away from the old "schedule" concept because it
doesn't do a very good job of detailing what is really going on for a
given path.

That said, the "node" functions are present to help with the
transition away from entry_t (and access batons and whatever). So if
you want to make a node function to return the old-school schedule
value, for expediency, then go ahead. Eventually, we'll track down all
callers and figure out the Right Change.

Note that questions.c has a function called
svn_wc__internal_is_replaced(). That is a Correct implementation for
determining the old svn_wc_schedule_replace state. You could use that,
expand on it, or wrap it and expose it to libsvn_client, if any of
that is helpful.

Cheers,
-g

On Tue, Sep 22, 2009 at 20:03, Dave Brown <dave.brown_at_wandisco.com> wrote:
> Hi all,
>
> I've been working on removing svn_wc_entry_t usage in
> libsvn_client/export.c. Most of the fields from wc_entry_t needed by
> export.c have fetch api's already (svn_wc_private.h / node.c), except
> wc_entry_t->schedule. I see that it =~ wc-ng's svn_wc__db_status_t, so
> I've added a fetch function for a node's svn_wc_schedule_t, akin to
> svn_wc__node_get_kind(), to translate wc-ng values -> wc_schedule_t. So
> I'd like to check - does this sound like the right track? If so, I have
> follow up questions on translating some of the svn_wc__db_status_t
> values (entries.c is doing this now).
>
> It also occurred to me that perhaps the plan is to promote the wc_db.h
> api's to be more public at some point, which might change how this sort
> of thing would be handled.
>
> If this all sounds close to "right" I'll send along a patch.
>
> -dave
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398693>