[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking branch has been merged [Re: svn commit: r13571]

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-03-25 08:14:22 CET

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.