Re: [PATCH] Introduce the translate_paths parameter to svn_ra_get_merge_info()

On Wed, 19 Jul 2006, Madan S. wrote:
...
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=117981, we
> decided to implement the translate_paths parameter for
> svn_ra_get_merge_info(). Actually dberlin mentioned thus:
> we really need to split include_parents into two arguments:
> use_parent_info
> and
> translate_paths
>
> This could be interpreted as: "give the use_parent_info param to more
> than just bool values and interpret the meaning at the fs-layer." But I
> decided to leave the include_parents param alone and use a new parameter
> because multiple values of include_parents will confuse the reader and
> hence would be difficult to maintain.
...
> [[[
> Introduce the translate_paths parameter, to conditionally append
> the basename of the target to the mergefrom source paths.
...

Would you describe the use case for this behavior? I'd like to
understand why it's needed (I assume in libsvn_client/diff.c).

I don't grasp every last detail here, but the behavior doesn't seem
valid to me. How can the client do path translation when it doesn't
have access to the repository FS? I discussed the following two cases
for translate_paths=false on IRC with DannyB:

1) When include_parents=false, we don't include inherited merge
history for the parents of the requested paths. Because of this, only
the requested paths themselves will ever be returned by the API,
meaning that the translate_paths parameter becomes irrelevant (other
than the fact that translate_paths=true isn't even a valid value
here).

2) Otherwise, when include_parents=true, you must make assumptions on
the client-side about how your non-translated path relates to your WC.
While most of the time these assumptions will turn out to be correct,
aren't there edge cases which could bite us when we don't have access
to the repos FS?

For instance, if you request merge info for /branches/foo/bar, and the
merge info for that path comes back "/trunk:1-5", but the path
/trunk/bar does not represent the same object as /branches/foo/bar
(e.g. if /trunk/bar was renamed to /trunk/baz, and a new /trunk/bar
has been created), appending "bar" to "/trunk" on the client side
isn't correct -- we need the merge info's source to be translated to
"/trunk/baz:1-5" (or whatever). I don't see how the client can do
this efficiently.