[PATCH][merge-tracking]get_merge_info_for_path eliding fails when ancestor has mergeinfo or null mergeinfo.(Take2)

[Kamesh Jayachandran <ka...@collab.net>]

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.

With regards
Kamesh Jayachandran

Re: [PATCH][merge-tracking]get_merge_info_for_path eliding fails when ancestor has mergeinfo or null mergeinfo.(Take2)

[Daniel Rall <dl...@collab.net>]

On Tue, 31 Oct 2006, Daniel Rall wrote:

> 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.

r22189 was a necessary follow-up to fix an interaction in
'merge_tests.py 4' between this change, and Madan's r22119 (recording
of implied merge info for copy sources).  It accounted for merge info
acquired during repos-to-repos copying which is now properly
inherited.

Re: [PATCH][merge-tracking]get_merge_info_for_path eliding fails when ancestor has mergeinfo or null mergeinfo.(Take2)

[Daniel Rall <dl...@collab.net>]

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.