Branko Čibej wrote: > On 14.02.2014 11:38, Julian Foad wrote:
>> Can we think of a better way to design the API so that it returns the >> interesting data without all the redundancy? Basically I think we want >> to describe changes to mergeinfo, rather than raw mergeinfo. > > I wonder, Julian, could something like this be useful for merge in general? > > We know that clients can cache most of the mergeinfo in the > repository, if they want to; I just don't have any feeling for how > much sense it would make to maintain such a cache, and if it can be > made smart enough to speed up merging significantly. I wasn't sure how much mergeinfo we fetch in a typical merge so I tried some merges with current svn branches. They all fetched mergeinfo either two or three times, all at the head revision, and the time taken to fetch it was not a substantial portion of the overall merge time. So I think the answer is we wouldn't currently benefit from this within the scope of one merge. (A persistent cache on the client machine is a different matter.) - Julian
