On Sat, Feb 14, 2009 at 04:46, Hyrum K. Wright
> On Feb 13, 2009, at 9:27 PM, Greg Stein wrote:
>> On Thu, Feb 12, 2009 at 07:17, Hyrum K. Wright <hyrum_at_hyrumwright.org>
>>> @@ -2141,28 +2091,12 @@ svn_wc_prop_list(apr_hash_t **props,
>>> SVN_ERR(svn_wc_adm_retrieve(&adm_access, adm_access,
>>> svn_path_dirname(path, pool), pool));
>>> - return svn_wc__load_props(NULL, props, NULL, adm_access, path, pool);
>>> -/* Determine if PROPNAME is contained in the list of space separated
>>> - values STRING. */
>>> + SVN_ERR(svn_wc__load_props(&base_props, &new_props, NULL, adm_access,
>>> + path, pool));
>>> -static svn_boolean_t
>>> -string_contains_prop(const char *string, const char *propname)
>>> - const char *place = strstr(string, propname);
>>> - int proplen = strlen(propname);
>>> + *props = apr_hash_overlay(pool, new_props, base_props);
>> I don't understand why the logic changed here. The removal of the
>> propcaching should not have affected the original svn_wc__load_props()
>> call. So why the addition of the overlay here?
> This isn't about propcaching, this is about getting the BASE props and the
> WORKING props and combining them. With propcaching, the working props were
> cached (iiuc) so there wasn't a need to fetch them, which is what's
> happening here.
> Or, propcaching is just confusing and this makes things work until we get
> the props moved into sqlite.
propcaching only told you whether one of three properties was present
on the node: externals, special, or needs-lock. It had nothing to do
with the values, and reading those from the files. Thus, you shouldn't
have had to change this code at all.
Simple logic: note that you did *not* modify svn_wc__load_props(), so
its behavior is unchanged on fetching property values, so you should
not have had to compensate in any way.
Received on 2009-02-14 04:51:03 CET