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

Locking functional spec: directory locks

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2004-10-13 07:41:03 CEST

The functional spec says:
> If a directory is locked, the owner of the lock has the exclusive
> right to change the directory's list of entries and properties, to
> delete the directory, and to move the directory. This lock applies
> recursively to all files and directories under the locked directory.

I believe that if we want our locking implementation to be within the
realm of acceptable simplicity, we need to punt on directory locks,
which address a completely different need from the sane handling of
non-mergeable files. For those who believe otherwise, please answer
the following questions:

  * Does the svn:lock property on a directory imply that every file
    underneath the directory must be locked before modification, and
    should therefore be read-only in the working copy when not locked?

    - If not, then I can locally modify a file and someone else can
      later lock a directory above it, leading to a conflict on a
      locked file, something which isn't supposed to happen without
      hijacking of some form. So I will assume yes.

  * When the client checks out a directory, how does it discover
    whether one of the parent directories has the svn:lock property,
    so that it can know whether to make all the files read-only?

  * When the client checks in a locked file, the lock is normally
    released, but the "lock" may actually be a parent directory lock,
    in which case it is presumably not released unless the checkin
    covered the entire parent directory. How does the client
    determine whether the file should be reverted to read-only state?

I can probably come up with more questions later. Is this feature
really worth a whole new class of ghudson bugs?

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