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, ...)?
That's great, thanks. I added a reference to this email thread, added myself to the CC list, and tweaked the type from 'feature' to 'enhancement' (just my personal interpretation) and schedule from '---' to 'unscheduled' (which just indicates I've thought about it and am stating that it's not currently tied to any particular release, it doesn't mean it has to stay that way). I talked with Brane about this and we discussed how it might make more sense to do a higher level API. Instead of asking "what is the absolute difference in the mergeinfo representations?" it could ask "What merges and other interesting events have occurred in the lifetime of this path?". There are a couple of reasons. The API as sketched so far is pretty straightforward, but even so the effort needed to implement it is not trivial. It requires RA protocol changes as well as all the layers of API change. The mergeinfo representation is subject to change. It feels like a backward step to invest effort in adding more support that is tied specifically to the current format. 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? Does your code already calculate something like that? - Julian
