[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH][merge-tracking] remove redundant for loop in svn_fs_merge_info__get_merge_info

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2006-10-11 15:03:26 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.