[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn_ra_get_merge_info() quirkiness.

From: Madan U Sreenivasan <madan_at_collab.net>
Date: 2006-07-17 14:45:15 CEST

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
Received on Mon Jul 17 14:15:22 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.