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

Re: svn_ra_get_merge_info() quirkiness.

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-07-17 17:30:51 CEST

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

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

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.