Hey Hyrum,
Per our IRC conversation, I'm concerned about removing the internal
caching of the entries hash. Some functions, contrary to the docstring
of svn_wc_entries_read(), modify the returned hash with an expectation
that the changes will "stick" until something syncs/writes those
changes to disk. In particular svn_wc__entries_modify() is one of
those functions. Before any further removal of the caching can be
done, the callers who expect this modify-in-place behavior will need
to be rewritten.
I found there are 5 callers of svn_wc_entries_read() in libsvn_client,
and 42 callers in libsvn_wc.
Examining libsvn_client, I see the following breakdown:
commit.c: wants count of versioned children
commit_util.c: uses values as const
export.c: uses the keys (names) and entry->kind
merge.c: two uses that only use the hash keys (ie. they want the names
of the children)
In short, all of these uses are "safe" and within the confines of the
intended usage.
For future reference: it seems that libsvn_client would want a
function to return a list of the children's names (hitting 3 of the 5
uses). export.c wants the kind, and commit_util needs "everything".
Note that I'm not examining svn_wc_entry() calls her. That returns a
"const" value, so I doubt anybody is attempting to modify the entry
in-place.
I have not (yet) examined the libsvn_wc uses. If anybody will "play
games", then it will be in there, where there is some level of
knowledge of the internal workings of the library.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1351366
Received on 2009-03-19 00:16:44 CET