Ben Collins-Sussman <sussman@collab.net> writes:
> > 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.
Didn't say a thing about not caching the token. This discussion is
about a reporting mechanism, not implementation detail of an
auth-of-sorts system.
> > 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...
Turns out I'm not (nor was I) missing that fundamental idea at all.
> 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?
Not only was that my "next logical question" -- it was my only
question.
> 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.
There. *Finally* a legitimate argument for this display. Thank you.
> 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.
(But then, sadly, back to an illegitimate one that has nothing to do
with reporting lock information in 'svn info'.)
> 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. :-)
That analogy is fairly unreasonable, and I think you know that. Nor
is it relevant to the questions I raised.
Anyway. So yes, I agree, it makes sense to indicate to the user that
his working copy thinks he is holding a lock. And that's what status
does. Does info need to reveal the lock token, owner (which is
generally speaking pretty silly since the owner is almost surely the
owner of the whole working copy), comment, and expiration date? Well,
again, that's the question I asked in the first place. And to be
*really* clear, I questioned not that 'svn info' reported this
information -- I questioned that it reported the info as something
that was reliable or unquestionable.
Soothing my specific concerns might be as simply as 'svn info' making
clear (preferably in its output, but I suppose its usage message would
be okay) that the information it reports about working copy paths is
limited in scope to what the working copy knows at the time, and that
is very possible that the information could be stale (and therefore
unreliable). I mean, maybe we just need to put asterisks by the field
names which could possible be stale (the lock stuffs, revision
author/date stuff, etc.) like footnotes about their reliability.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 25 05:29:24 2005