Bruce Wilson wrote:
>
> 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?
How about the 'Last Changed Rev:' field of 'svn info URL'?
In your working copy 'svn info' will tell you which revision had the
last change on any particular file - but this is cached as of your last
update and not useful if you want to know about subsequent repository
changes.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 27 00:09:44 2007