WC Hacking Question: Different svn_wc_entry_t depending on svn_wc_adm_access_t lock depth

[Paul Burba <pb...@collab.net>]

While fixing an update bug in r25023 I came across something that
puzzled me and was hoping that some of you more familiar with the sparse
directories could comment.

Let's say we checkout a vanilla greek working copy to WC_PATH with
--depth immediates, so we get only 'A' and 'iota'.

Then we perform some operation (e.g. svn up --depth immediates) that
opens an access for the root of a working copy path 'WC_PATH' with a
lock depth of 0 in svn_client__update_internal().  Using that access, we
then get an svn_wc_entry_t for the dir 'WC_PATH/A', using
svn_wc__entry_versioned() --> svn_wc_entry().

The docstring for svn_wc_entry() seems to indicate that this is not ok,
because the only access we have is for the root of the WC, not for
'WC_PATH/A':

 * If @a path is not a directory then @a adm_access must be an access
baton 
 * for the parent directory of @a path.  To avoid needing to know
whether 
 * @a path is a directory or not, if @a path is a directory @a
adm_access 
 * can still be an access baton for the parent of @a path so long as the

 * access baton for @a path itself is in the same access baton set.

But the call to svn_wc__entry_versioned() succeeds and we get an
"incomplete" entry for 'WC_PATH/A', all we really have is name, kind,
and schedule (i.e. the info in 'WC_PATH/.svn/entries' regarding 'A').
If the access had been opened with depth == -1 then the entry for
'WC_PATH/A' would be complete (i.e. corresponding to the 'this dir' info
in 'WC_PATH/A/.svn/entries').

Is this what people expect?  Do we rely on this behavior?

If so, I'd say the docstring for svn_wc_entry() needs improvement.  Do
we have some official term to refer to these "incomplete"
svn_wc_entry_t's?

Paul B.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org