Re: Locking functional spec: read-only WC

Ben Collins-Sussman wrote:

> Suppose somebody tries to commit a hijacked file that has the
> 'svn:must-lock' property attached. My instinct is that they get an
> error saying "get a lock first!", regardless of whether someone has
> already locked the file or not. This teaches the user to stop hijacking.

Perhaps the conceptual thing I am stuck on is that file/directory
locking can happen without the svn:lock property being set. Here, the
WC has no notion that the file is locked until commit time, which
violates the goal in I.A.2. to provide a communication mechanism to
prevent needless editing which will be blocked by locks.

I can see the utility for non-mergeable files of forcing the lock to be
obtained in advance of the commit (and I've reread the Hijack section
again now ;). But if we are to permit locking of files without setting
the flag, how is that going to facilitate communicating that the file is
locked now?

What we really need is not a flag but a tri-state:

1) this file must be locked before editing (binary/non-mergeable)
2) this file can be locked (mergeable files)
3) this file cannot be locked

then this would fit all of our needs. People who don't want to permit
locking set #3 at the root of the repository (and all files would
inherit it). The normal state would be #2 (matching the current
behavior, mostly), and the exceptional case would be #1.

What I was thinking about for inherited properties would fit neatly into
this model:

1) when checking out a file, the server would send additional properties
based on the inherited state at that point (to allow for checkouts at
different revisions); this could include

        svn:lock,
        svn:property:customprop,

or any other inherited property; as stored in the repository, the
attribute could be at the file or directory level and the server would
be responsible for walking the tree to determine the current state.

2) when the WC is updated, the server would treat changes in inherited
properties as updates (so a new lock would suddenly show up on a file),
and "svn st -u" would report the same information.

3) the WC would maintain a list of properties (both real and inherited)
at the rev of last update, and behave appropriately (whether that would
be expanding custom keywords or setting the WC file to be readonly when
a lock is initiated).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org