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