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

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

From: Marc Strapetz <marc.strapetz_at_syntevo.com>
Date: Wed, 19 Feb 2014 17:22:54 +0100

On 19.02.2014 16:06, Julian Foad wrote:
> Marc Strapetz wrote:
>> Julian Foad wrote:
>>> It looks like we have an agreement in principle. Would you like
>>> to file an enhancement issue?
>> Great. I've filed an issue now:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=4469
>> Would you please review the various attributes (Subcomponent,
>> ...)?
> [...]
> SmartSVN and other front ends like to be able to draw a merge graph.
> Even the 'svn mergeinfo' command-line command now draws a little
> ASCII-art graph showing limited information about the most recent
> merge. At present they all have to interpret mergeinfo themselves, at
> a pretty low level, and the interpretation is subtle and poorly
> understood. (I don't understand the edge cases related to adds and
> deletes properly, and I've been working with it for years.)
> So it seems like a good idea to encapsulate the interpretation of
> mergeinfo a bit more, and expose data in a form that is geared
> specifically towards explaining the history in the way that users can
> understand it. Maybe think of it as an extended 'log' operation,
> adding a small number of new notification types such as:
> * there is a full merge into here, bringing in all the new changes
> from PATH up to REV;
> * there is a partial merge to here, bringing in
> some changes from PATH between REV1 and REV2;
> What do you think of that sort of interface?

That definitely sounds good. Just to note that the
extended-log-information should be easily receivable and cacheable for
the entire repository and it must be rich enough to easily extract
information for a specific path.


- allow to include/exclude subtree merges for merge arrows

- allow merge arrow display for sub-directories and individual files

Ultimately, when having received all extended-log-information for all
revisions, one should be able to recreate raw svn:mergeinfo for all
paths of all revisions. I think this will guarantee that we won't miss
any possible use case when defining the protocol and data structures.

> Does your code already calculate something like that?

Yes, and I recall having a hard time when writing this code :)

Received on 2014-02-19 17:23:31 CET

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.