Karl Fogel wrote:
> "Mark Phippard" <markphip@gmail.com> writes:
>
>> I am skeptical that caching this information would make a significant
>> performance difference, and I am very much against this regardless.
>> We also use this API in Subclipse. much like TortoiseSVN does. While
>> I would love for it to run faster, I need the information to be
>> accurate, including the revision number. If you simply cache the
>> information once you know an item is out of date, then you no longer
>> are guaranteed to have an accurate revision number. That would be a
>> show-stopper for me.
>>
>> Like I said, I am in favor of making something faster if it can be
>> done. But I also need the API to continue to be completely accurate.
>>
>
> Well, these two goals are not in conflict. It would be perfectly
> possible to design different APIs for "Is this file out of date?" vs
> "What is the most recent revision in which this file was changed?"
>
> The fact that the latter question is effectively a superset of the
> former, and that the current API only offers the latter, does not
> limit what we do with future APIs.
>
Hmm, what I was hoping for was more along the lines of
file-contents-have-changed. Doesn't the server have easy access to this
info within the repository? That is, a cheap way to determine that revs
9920 and 9987 are identical because they point at the same physical storage?
Hmm, but even at that, this may not be 100% accurate. If a file is
modified twice and ends up the same, a simple same-file test probably
isn't stored that way in the repository. How about an edit and a
reverse-merge?
Received on Mon Nov 26 23:38:40 2007