svn_ra_get_merge_info() quirkiness.

[Madan U Sreenivasan <ma...@collab.net>]

Hi,

    In the merge-tracking branch:

    I have trouble understanding the cache hash thingy used in the  
get_merge_info_for_path() function. Am especially not in favor  of   
append_component_to_paths() (actually I think what  
append_component_to_paths() does is wrong)

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

   The value being the mergeinfo available for /branches/branch1.

   But what I get is:
     Key: /branches/branch1/cc
     Value : /trunk/cc: 3-4, 7-8

   I think this quirkiness is because of append_component_to_paths(). Or  
maybe I dont understand it well enough.

   Could somebody explain get_merge_info_for_path()'s caching mechanism and  
why append_component_to_paths() does what it does pl.

Thanks and Regards,
Madan.
 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn_ra_get_merge_info() quirkiness.

[Daniel Berlin <db...@dberlin.org>]

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