> > Hrmm... I sense a bit of a culture clash going on. The SVN
> > client and any command line shell can already do what you
> > ask. Just run 'svn status -u > status.txt' and *poof* you
> > have your cached information.
> > You can even script it to do 'svn info' and diffs on the updates.
> >
> > So it's not a new feature being asked for, instead, a better
> > way of presenting the data is desired. GUI clients should
>
> Indeed, that is exactly what I am suggesting. By cacheing the results
> of a server query in a local file of standard format, GUI clients can
> create a means to show that information in a consistant fashion. That
> part does not exist now. That is what I am saying SHOULD exist.
Caching is the problem with all the negativity here. GUI clients
already have all the means (read: APIs) available to present you the
right icons. The only thing they have to do is query the server real
time (or better: read-ahead). So, basically, the entire discussion is
moot, because everything required is there.
Caching is a problem because it has a high chance of presenting
incorrect results. Users learn to deal with incorrect results by
ignoring them, meaning that caching doesn't add any value.
> > already be able to do something pretty with that information
> > with the current version of SVN. This sounds more like a
> > request better handled by clients like TortoiseSVN.
>
> With that assertion, it falls on each GUI client to unilaterally create
> their own means to cache and display the data.
No. They shouldn't cache it (apart from in-memory after a read-ahead
operation) and use the operations available since Subversion 1.2.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 20:59:50 2007