[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-11-28 15:35:05 CET

On Nov 28, 2007 9:25 AM, Harvey, Edward <Edward.Harvey@patni.com> wrote:
> There doesn't seem to be much discussion in this thread anymore. Based
> on what I've seen so far, it seems that if svn caches the results of
> "svn status -u" for the benefit of gui clients to remember which files
> are already out of date, some people here will choose not to use that
> information, but nobody seems to object saying "it shouldn't exist for
> anyone."
> No objections right?
> In fact, a number of people think it's a good idea, right?

I think it is pointless and that TortoiseSVN would likely not use the
feature. 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. I am not convinced that
is a compelling use case and there are some variable involved that
might make it not give the desired results anyway (namely there is no
reason TortoiseSVN would know to refresh its cache).

Mark Phippard
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 28 15:35:50 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.