[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: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-11-28 18:28:11 CET

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
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:27:28 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.