Les Mikesell <lesmikesell@gmail.com> wrote on 11/28/2007 11:28:11 AM:
> kmradke@rockwellcollins.com wrote:
>
> >> Better answer: cached status information is never reliable. If you
want
> >
> >> to know about the state of concurrent operations you have to ask the
> >> server since it is the only thing that knows. But I think the
> >> discussion has moved on to whether there should be an official api to
> >> store this unreliable information. If you expect multiple GUI
clients
> >> to be concurrently running and always display the same info you are
> >> going to need a lot of synchronization and locking gunk that doesn't
> >> seem to belong in a core api - and if it doesn't do that, what's the
> >> point of adding more than you'd get with 'svn -u status >file'?
> >
> > It is reliable when taken in the context of when it was gathered.
>
> So it might be useful if every display of the cached information also
> showed a timestamp of when it was last checked.
Exactly!
> > Just as you would expect your hard drive cache to be smart enough
> > to not use out of date information when you read file contents.
>
> Which turns out to be quite complex when concurrent operations are
> happening - note the problems with BDB on NFS.
Which is why there are a number of very good books on cache coherency
and a number of network filesystems that do this correctly.
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 18:33:29 2007