Madan U Sreenivasan wrote:
> Hi,
>
> In the merge-tracking branch:
>
> I have trouble understanding the cache hash thingy used in the
> get_merge_info_for_path() function.
Okay, so what is the trouble?
It is a cache of mergeinfo.
It is separate from the output because we can't put everything in the
output in the cache.
It also does negative caching to avoid looking up things we've already
discovered do not exist.
Am especially not in favor of
> append_component_to_paths() (actually I think what
> append_component_to_paths() does is wrong)
It's actually provably right, assuming the path exists in that revision.
It just may not do what you want.
>
> My case is as below:
>
> I have the following structure
>
> /trunk
> /branches/branch1
> /branches/branch1/cc
>
> Both branch1 and cc were created by copyin from trunk (now, cc is under
> branch1 as a theoritical case only - it helps me test eliding)
>
> now, assuming that branch1has the following mergeinfo:
> /trunk: 3-4, 7-8
>
> from cc, If I do a:
> svn merge ../../../trunk -r 5:6
>
> internally, svn_ra_get_merge_info() is getting called, for obtaining
> the elided mergeinfo (well, at least in my working copy ;). I expect
> svn_ra_get_merge_info() to return the following hash:
>
> Key: /branches/branch1/cc
> Value : /trunk: 3-4, 7-8
This is what it used to return, but dlr felt this was confusing.
After all, this is not directly usable (you can't apply /trunk to
/branches/branch1/cc).
If this is the output you want, i'm happy to make it give you that output.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 17 17:32:27 2006