[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Communication of CHANGES

From: Bruce Wilson <b-svn_at_toomuchblue.com>
Date: 2007-11-26 23:37:58 CET

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
Received on Mon Nov 26 23:38:40 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.