Re: [PATCH][merge-tracking]get_merge_info_for_path eliding fails when ancestor has mergeinfo or null mergeinfo.(Take2)
On Thu, 19 Oct 2006, Kamesh Jayachandran wrote:
> Hi All,
> Ignore my earlier patch with the subject '[PATCH][merge-tracking]
> get_merge_info_for_path eliding fails when grand parent has mergeinfo or
> grand parent has null mergeinfo.' located at
> The attached patch fixes one logical flaw in that patch.
> get_merge_info_path fails in the following cases,
> a)if the path is '/a/b/c/d/e' and the repo has the mergeinfo only for
> '/a/b/c' and no direct mergeinfo for '/a/b/c/d'.
> b)if the path is '/a/b/c/d/e' and the repo has
> null mergeinfo(meaning record in mergeinfo_changed and no record in
> mergeinfo) for '/a/b/c' and no direct mergeinfo for '/a/b/c/d'. The moment
> 'null mergeinfo' is encountered eliding has to stop.
> * subversion/libsvn_fs_util/merge-info-sqlite-index.c
> No need to flag null mergeinfo with 'has_no_mergeinfo' they can be better
> signalled with NEGATIVE_CACHE_RESULT for the 'path' in the cache hash.
> No need of 'pathresult' variable as we can use 'cacheresult' itself.
> When we have null merge info signal the same by setting 'cache' hash for the
> key 'path' with NEGATIVE_CACHE_RESULT.
> As long as we have a record in 'mergeinfo_changed' for this path and
> revision<=rev return no need to recurse further.
> Irrespective of 'result' translate the hash keys of 'elided parent->path'
> and set it to cache, so that we don't loose the 'mergeinfo' of '/a/b/c'
> during unwinding phase of recursion with path '/a/b/c/d'.
Committed in r22184 with some tweaks, along with the test case posted
on October 27th. Nice work, Kamesh.
Received on Tue Oct 31 22:22:03 2006
- application/pgp-signature attachment: stored
This is an archived mail posted to the Subversion Dev