> I think it is pointless and that TortoiseSVN would likely not use the
> feature.
Let's try to stay productive, shall we? Obviously it's not pointless.
End of story.
As for whether or not tortoise would use it ... Please see below.
> If SVN caches the information, that means the way to get the
> information out of the cache is to run the status API, perhaps a new
> one. This did not perform well enough for TortoiseSVN (or Subclipse)
> so we both have our own caches. Yes it is populated by running that
> same status API, but that also means we can already cache this out of
> date information. The only benefit you might get from having this in
> SVN is that if the user checked the remote status in Subclipse, and
> something else triggered TortoiseSVN to refresh its cache, then it
> would possibly get that information for free.
You bring up a good point, about tortoise using its own separate cache.
And that there's nothing triggering tortoise to update its cache. But
it's not true that a user would have to check for updates in subclipse.
More likely, somebody would check for updates on the command line (batch
script) or actually create the equivalent of a cron job inside tortoise
itself.
As for tortoise updating its cache, I've always felt there was a problem
there. Even the way tortoise is built now, I'll frequently edit a file,
and see the icon indicates "up to date" or whatever. I have to refresh
my window to get tortoise to show the file locally modified. So the
problem of tortoise not updating its cache frequently enough is a
tortoise problem, not a subversion problem, and certainly not isolated
to the idea of remembering that a file is out-of-date.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 30 01:49:01 2007