"Mark Phippard" <markphip@gmail.com> wrote on 11/28/2007 08:35:05 AM:
> 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).
A majority of our 1500 users are using multiple clients, and many
have expressed concern that clients can (and do) show conflicting
information about the same working copy.
A real user quote: "How can I trust Subversion if it can't even
consistently show status information between clients?"
A consistent cache (if possible) would not be pointless in our
environment.
I'll admit, if it is a lot of work, or has potential for showing
even more incorrect information it definitely shouldn't even be
considered.
Ignoring the technical aspect, (which most of us engineers have
great difficulty doing), we need to consider that a lot of new
and potential Subversion users do not have a technical background.
In fact, I used to work for a small company that forbid engineers
from doing any user interface design, since while functional, an
user interface designed only by engineers usually only makes sense
to other engineers.
Kevin R.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 28 16:14:53 2007