Marc Strapetz wrote:
> On 17.02.2014 18:36, Julian Foad wrote:
>> Marc Strapetz wrote:
>>> Hence an API like the following should work well for us:
>>>
>>> interface MergeinfoDiffCallback {
>>> void mergeinfoDiff(int revision,
>>> Map<String, Mergeinfo> pathToAddedMergeinfo,
>>> Map<String, Mergeinfo> pathToRemovedMergeinfo);
>>> }
>>>
>>> void getMergeinfoDiff(String rootPath,
>>> long fromRev, long toRev,
>>> MergeinfoDiffCallback callback)
>>> throws ClientException;
>>>
>>> This should give us all mergeinfo which affects any path at or below
>>> rootPath.
[...]
>> let's use the simpler version that's sufficient for your use case.
>
> That will be fine.
[...]
> From cache perspective it's easier to build the cache starting at r0:
> [...] Anyway, I agree that receiving mergeinfo for more recent
> revisions first is reasonable as well. Hence if you say the effort is
> the same, then we could allow both: fromRev <= toRev, in which case we
> will received mergeinfo in ascending order and fromRev > toRev in which
> case it will be descending order?
Could do. It seems like a relatively minor decision.
>>> [...] important that ranges for which no mergeinfo diff is present
>>> will be processed quickly on the server-side, otherwise we could run
>>> into some kind of endless loop, if the cache building process is
>>> shutdown and resumed frequently.
>>
>> [...] There is a client-side work-around: request ranges of say a thousand
>> revisions at a time, and then you can easily keep track of how many of these
>> requests have been completed.
>
> OK, that will work.
It looks like we have an agreement in principle. Would you like to file an
enhancement issue?
http://subversion.tigris.org/issues/
When you are logged in, that page includes links for filing a new issue. Please
note that filing an issue doesn't affect whether or when the work will be done,
but it's useful as a central place to refer to the task.
Do you have the resources to work on implementing this or are you looking for a
volunteer?
- Julian
