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
> 'http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=120709'.
>
> 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
> (get_merge_info_for_path):
> 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.