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.
Examples:
- 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 :)
-Marc
Received on 2014-02-19 17:23:31 CET