[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: <kmradke_at_rockwellcollins.com>
Date: 2007-11-28 18:33:07 CET

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
> >
> >> 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
> >> 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.


> > 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

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.