Re: [PATCH][merge-tracking]get_merge_info_for_path eliding fails when ancestor has mergeinfo or null mergeinfo.(Take2)
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
Received on Tue Oct 31 23:36:51 2006
- application/pgp-signature attachment: stored
This is an archived mail posted to the Subversion Dev