On Mar 24, 2005, at 9:23 PM, C. Michael Pilato wrote:
>
> I believe it is an oversight that 'svn info' ever reports information
> about locks as fact without consulting the server first.
So would you have 'svn status' hide the lock too?
> In other
> words, why are we ever reporting as fact data harvested from caches
> which can very easily become stale?
Because it's critical data. The fact that it can become stale is a
fact of life that we must deal with, it's not an option to *not* cache
the token.
> What may we reasonably expect a
> user to do while disconnected from a network with the information that
> as of the last time he updated, he held a lock on some file? Unlock
> it? (Nope, that requires network access.) Feel good that nobody else
> has it locked? (Nope, it could have been stolen out from underneath
> him.)
>
I think you're missing a fundamental idea here...
A 'lock' in the working copy isn't just some cute conveience that we
happen to cache so that things are pleasant for users when they're
offline. It's a very special type of authentication credential, one
which grants the working copy the right to make use of a lock in the
repository. And yes, the authentication credential has the ability to
go stale -- just like a cached password can go stale if an
administrator changes the user database. There's nothing we can do
about that, other than make 'svn update' detect the staleness.
So your next logical question, then, is: why do we display the
lock-token credential at all? Why does 'svn status' or 'svn info
wcpath' bother? Why not just hide the credential just like the cached
passwords in ~/.subversion/auth/ are hidden?
The answer is: the lock-token is much more important than the secretly
cached password. First of all, it's time-sensitive; every minute you
have a lock, others are blocked from changing the file. So it's good
for 'svn status' to remind you of this fact. Second, the existence of
token has a tangible effect on the working copy. If the svn:needs-lock
property is being used, the token's presence affects whether the file
is read-only or read-write.
So the cached token represents both an authn credential, as well as an
"action in process". It needs to have tangibility to the user, and be
an active, visible part of the working copy.
To answer your last question: "what may we expect a user to think when
he sees a lock-token while offline? Be lulled into a false sense of
security?" Of course not. If documentation is written well, users
shouldn't forget the fact that locks can be broken. The lock-token
isn't displayed to give the user a happy feeling of power; it's there
to remind the user that something is in process.
Just because locks are breakable doesn't mean the existence of a
working copy token is meaningless. That's like saying that looking at
a file's contents while offline is "meaningless", because a newer
version of the file might exist in the repository. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 25 04:59:11 2005