On 18.02.2014 15:26, Julian Foad wrote:
> 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?
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, ...)?
-Marc
