On Thu, 2005-03-24 at 22:04, C. Michael Pilato wrote:
> As I pointed out to Ben just yesterday, there are problems with even
> having last-changed-rev, last-author, and last-changed-date cached in
> the working copy. I mean, the latter two of those things are
> completely mutable as properties of the first.
> 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.
I agree with you. Had I realized earlier on that the locking branch was
caching data about *other* people's locks in the working copy, I would
have spoken up then.
(Caching last-author and last-changed-data data doesn't bother me as
much since those rev props aren't expected to change much. But locks
are expected to be transient.)
Ben wrote:
> Because it's critical data.
I don't think think this view is consistent with our architecture. The
preferred communication mechanism about locks is the svn:needs-lock
property, which prevents you from editing a lock-worthy file without
first trying to take out a lock. When you try to take out the lock, you
find out about the other person's lock.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 25 08:16:11 2005