Daniel Berlin wrote:
>> Index: subversion/libsvn_fs_util/merge-info-sqlite-index.c
>> ===================================================================
>> --- subversion/libsvn_fs_util/merge-info-sqlite-index.c (revision 21862)
>> +++ subversion/libsvn_fs_util/merge-info-sqlite-index.c (working copy)
>> @@ -519,18 +519,12 @@
>> for (i = 0; i < paths->nelts; i++)
>> {
>> const char *path = APR_ARRAY_IDX(paths, i, const char *);
>> + apr_hash_t *currhash;
>> + svn_stringbuf_t *mergestring;
>>
>> SVN_ERR (get_merge_info_for_path (db, path, rev, *mergeinfo,
>> mergeinfo_cache, TRUE,
>> include_parents, pool));
>> - }
>> -
>
> Uh, changing this like you have would be a bug waiting to happen.
> There is no guarantee that *mergeinfo isn't going to get info about
> path from a *later* call to get_merge_info_for_path, so it's not
> enough to just lookup the info immediately after the call for *that*
> path.
You mean later call's can overwrite the mergeinfo hash for the same key?
Two things,
1)'get_merge_info_for_path' can touch 'mergeinfo' only for the given
path not for any other parent path.
2)if the 'paths' array has duplicate 'path' 'get_merge_info_for_path'
would return some info which should be same or atleast the latest
info(due to fresh commits) which should be fine to consume immedeately,
instead of one more for loop.
If you consider the mergeinfo alzebra of converting apr_hash_to to
'svn_merge_rangelist'... is costlier may be we can change the signature
of paths from 'apr_array_header_t *' to 'apr_hash_t*'.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 11 15:03:03 2006