> -----Original Message-----
> From: Erik Huelsmann [mailto:ehuels@gmail.com]
> Sent: Wednesday, November 21, 2007 2:59 PM
> > > 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.
Get rid of the base files in .svn then. Require that whenever a user
wants to see differences, they hit the server. Until you do that, the
argument you present is invalid. The fact that the revision "still
exists" in the server is not a valid response. As far as the user is
concerned, the local information is no longer accurate with respect to
doing their job. When I launch a "diff", it always shows me the diff
verses my local base unless I _explicitly_ query the log or look at
Tortoise's "status -u" window. Thus, the cached data is "incorrect",
just as it would be for a lock cache. "Incorrect results" is a red
herring. "Out of date results" is more truthful.
>
> > > 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.
On what basis are the icons displayed at this point? Are you suggesting
a thread be spawned to check the server every few seconds? Without a
local cache of last known information, I fail to see how the icons can
be maintained in the face of a re-render. Also, the in-memory cache
would have to be implemented on a per client design, which I already
explained is a problem.
>
>
> Bye,
>
>
> Erik.
>
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 26 17:27:07 2007