[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-10-13 16:08:47 CEST

On Oct 13, 2004, at 9:09 AM, 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.
>
> 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.
>

Thanks for saying this, Greg. I was about to write the same thing to
Justin. :-)

There are two scenarios here:

1. An admin wisely puts an 'svn:lock' property on an image file.

    This means that the file is read-only most of the time, and users
*must* obtain a lock before they can start editing; this prevents
people from wasting time on unmergeable changes.

2. Justin's team is collaborating on a mergeable text file.

    This file would have so such 'svn:lock' property or resultant
read-only attribute. It's still lockable by anyone, and the lock is
still enforced by the server at commit-time. But folks are still free
to concurrently edit local copies, even when somebody has locked it.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 16:09:11 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.