Moore, Tom wrote:
>> If you cache the information people will see it and believe it. And
>> because it's right most of the time this will re-enforce the idea that
>>
>
>
>> the information is correct. Users will come to rely on the information
>>
>
>
>> to make important decisions. Sometimes the results will be
>>
> catastrophic.
>
>> It has been my experience that the likelihood of such a problem will
>> occur is inversely related to the amount of time available to do a
>> project and directly proportional to the importance of finishing on
>>
> time.
>
> You know there is a basic assumptions here that a number of people are
> making that is driving a lot of the negativity, and driving some of us
> nuts.
>
> "The cached information is a binary solution set. Locked or Unlocked.
> People will view the cache and assume or believe..."
>
> The first thing I have to say about that is that people do NOT see the
> cache. They see what the client tells them based on what it sees in the
> cache.
>
> There is absolutely NO reason that a file cannot be marked to indicate
> that the file was locked by another user at last status, update,
> checkout, etc. but this data is informational and potentially out of
> date, then users are being TOLD not to rely on it. How do you do that?
> In a GUI they just use a different icon. In the command line, the only
> way I know that they would even *see* this information is by running a
> status command and if this modification were made, the status command
> could return a value of "Potentially out of date, run status -u to see
> current lock status" or something similar if it finds a cached lock
> value from another user. Any of the other commands we discussed (status
> -u, get-lock, update, checkout) all touch the server directly. If this
> modification were made, they would know whether the cached data was up
> to date or not and would know whether to update, clear or leave alone
> the cache in order to present the correct data.
>
> When was the last time you looked at a file either through a command
> line or a GUI and saw all the cached data about the file without issuing
> extra commands? Svn isn't integrated with ls or dir, so any subversion
> related data about files can only be acquired through a subversion
> command. GUI's show a little more with the cute icons, but they don't
> show everything and still require specific commands to show more data.
> The choice of what to show *AND* how it's shown is up to the client
> implementation. However, failure to pass or cache that data when it's
> available restricts the capability of the clients to be able to show it
> if they desire unless they go off and implement modified versions of
> these commands, which could then leave them potentially incompatible
> with the other client implementations.
>
I am not sure why your are focusing on files with the locked status in
the cache (false positives.) They are not the problem at all. The
developer will see that they were locked at one time and figure out
whether they are still locked and do the right thing.
It is the false negatives that will cause the problems. The developer
will look at his working copy see no lock and start modifying the file.
Only later he'll find out it's locked. That's when you have a problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 21:46:14 2007