On Sat, Feb 14, 2009 at 04:46, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> 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.
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.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1155132
Received on 2009-02-14 04:51:03 CET