> 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.
FYI, go read subversion/include/svn_wc.h... unless I'm reading the code
wrong (always possible as my C is rusty) the data structure for an item
entry in a working copy already contains all the fields to be able to
implement this and has since version 1.2.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 21 20:43:26 2007