Re: Communication of CHANGES

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.

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

-- 
   Les Mikesell
    lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org