Ben Collins-Sussman <sussman@collab.net> writes:
> On Mar 24, 2005, at 9:04 PM, C. Michael Pilato wrote:
> >
> > This continues to be a concern for locking stuffs, too, where a
> > working copy might claim that a lock is held on a given resource, but
> > in truth, that lock could have been broken a week ago and the working
> > copy just be out of date.
> >
>
> That's not an oversight, that's a predicted scenario with code paths
> to compensate. That's the reason tokens are reported during 'svn
> update': so updates can remove "defunct" tokens.
Oh, I know it's not an oversight that tokens can be stolen. Not
questioning that.
I believe it is an oversight that 'svn info' ever reports information
about locks as fact without consulting the server first. In other
words, why are we ever reporting as fact data harvested from caches
which can very easily become stale? 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.)
> But in the larger picture, there *is* a general problem with caching
> mutable server metadata, situations we haven't planned for. The
> svn:date and svn:author revprops can change, and unless a file is an
> exact target of an update, there's no way its cache of these things
> will ever be synchronized. The same is true for the cached
> lock-comment. Are these things to worry about? Should we file a
> bug?
I don't see these two problems as any different, save for maybe the
fact that we propogate the revision metadata a little more readily via
keyword substitutions.
---------------------------------------------------------------------
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:27:39 2005