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

Re: Locking functional spec: read-only WC

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-10-13 17:32:06 CEST

On Wed, Oct 13, 2004 at 09:09:19AM -0400, Greg Hudson wrote:
> I think you're missing a fundamental aspect of the locking design. The
> svn:lock property does not mean the file is locked; it means the file
> *must be* locked before editing. Locks themselves are not represented
> by properties. The working copy will learn about contention when it
> tries to get the lock.

Uh, then, I don't think that's such a good idea. Locks really should not have
to be pre-declared. I should be able to lock any file at any time.

(FWIW, the locking UI doc doesn't really make this clear. I guess Ben thought
that, but I don't think it comes across from the doc unless you already
know that is how it works. This is certainly very different from our
previous locking strategies.)

> So the working copy does not have to know whether anyone else has a lock
> on the file. It only has to know whether itself has a lock, which is
> easy.

The model I am thinking of here is Dreamweaver's locking system. A file may
be in one of two states:

- No lock is present
- File is locked and someone holds it

Any file at any time can be locked. Forcing a pre-declaration seems really
odd. What's the justification? Or, are you saying that I could also have a
lock on a file that doesn't have the svn:lock property set? If so, that
certainly wasn't clear. And, if that's the case, I'd rename svn:lock to
'svn:mandatory-lock' or something. -- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 17:32:25 2004

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.