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> wrote:
>> ...
>> @@ -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.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1155110
Received on 2009-02-14 04:46:58 CET