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

Re: [proposal] API to obtain hereditary mergeinfo

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2006-07-18 16:30:08 CEST

Daniel Rall wrote:
> On Mon, 10 Jul 2006, Garrett Rooney wrote:
>
>> On 7/10/06, Madan U Sreenivasan <madan@collab.net> wrote:
> ...
>>> Currently, the mergeinfo merges from the source happen at only one
>>> level (i.e., from only the source directory/file). However, because we use
>>> the concept of eliding (store mergeinfo at the first most common point),
>>> there might be mergeinfo in the parent or grandparent which affects the
>>> current source file/directory.
>>>
>>> So, we need an API (or should it be a static function)
>>> svn_merge_hereditary_merge_info(), that takes recursively merges the
>>> mergeinfo from all its anscestors.
>>>
>>> I thought I could get your opinion before I go ahead and implement the
>>> same.
>> It does seem like we will need such an API, although I would run
>> things by one of the Dans to see if they had plans as to how it would
>> be implemented.
>
> How do you see this API differing from svn_ra_get_merge_info() (see
> its INCLUDE_PARENTS argument)?

So Madan wants it to merge all the parents info, instead of just falling
back to parents if no mergeinfo exists in the child.
I have no problem with this. The fact that we don't do this is a bug
(the design intended it, actually).

Madan also wants it to happen *without* the path translation we
currently do. Thus, we really need to split include_parents into two
arguments:
use_parent_info
and
translate_paths

--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 18 16:31:20 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.