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

Issue 533 - locking

From: D.J. Heap <dj_at_shadyvale.net>
Date: 2003-07-26 05:19:53 CEST

Here's a little patch to implement the core of kfogel's remarks in Issue
533 on locking. Basically it just stops the commit if a node has
the svn:locked property set to a username other than the committer's.

I realize this is a semi-religious (and post 1.0) issue, but it has
become a sticking point at our shop and with this bit I can make them happy.

I am willing finish it up and write regressions tests, update the
docs, add a 'svn lock' command if wanted, etc. but since I don't need
that here I would rather not bother if the functionality is not wanted
or this implementation of it will be rejected. :)

Another detail I wasn't really clear on from the remarks was whether or
not it was desirable to make a locked file read-only for other users --
I think that was the intent when the comments referred to libsvn_wc
paying attention to it, but I'm not sure?

Basically following the issue comments, locking the file means setting a
'svn:locked' property to the user's name -- only that user can commit
the file now, although it is easy to remove the property, of course.
That is a feature IMO, since it is more about notification than any real
security, and if the selfish jerk that locked the file goes on vacation
or is hit by a bus it's not really a problem.

Originally I had the code in libsvn_client, but I could not find a way
to reliably get the username (since they may not even have supplied it
yet) so libsvn_repos (where 'out of date' is handled when opening a
node) seemed the best place.

Is this the right idea and desired or not even close?


Index: subversion/include/svn_error_codes.h
--- subversion/include/svn_error_codes.h (revision 6580)
+++ subversion/include/svn_error_codes.h (working copy)
@@ -465,6 +465,11 @@
               SVN_ERR_FS_CATEGORY_START + 30,
               "Berkeley DB deadlock error")
+ "Cannot commit an item locked by another user")
   /* repos errors */
Index: subversion/include/svn_props.h
--- subversion/include/svn_props.h (revision 6580)
+++ subversion/include/svn_props.h (working copy)
@@ -198,6 +198,9 @@
+/** The username of the person who has the file locked */
 /** @} */
 /** WC props are props that are invisible to users: they're generated
Index: subversion/libsvn_repos/commit.c
--- subversion/libsvn_repos/commit.c (revision 6580)
+++ subversion/libsvn_repos/commit.c (working copy)
@@ -29,6 +29,7 @@
 #include "svn_fs.h"
 #include "svn_repos.h"
 #include "svn_md5.h"
+#include "svn_props.h"
@@ -276,6 +277,25 @@
   return SVN_NO_ERROR;
+static svn_error_t *
+check_for_lock (const char* path,
+ struct edit_baton* eb,
+ apr_pool_t* pool)
+ /* check for node locked by another user */
+ svn_string_t* lock_prop;
+ SVN_ERR (svn_fs_node_prop (&lock_prop, eb->txn_root, path,
+ SVN_PROP_LOCKED, pool));
+ if (lock_prop != NULL && lock_prop->data != NULL &&
+ !svn_string_isempty (lock_prop))
+ {
+ if (eb->user == NULL || strcmp (eb->user, lock_prop->data) != 0)
+ return svn_error_createf (SVN_ERR_FS_NODE_LOCKED, NULL,
+ "'%s' has been locked by '%s'.",
+ path, lock_prop->data);
+ }
+ return SVN_NO_ERROR;
 static svn_error_t *
@@ -297,6 +317,8 @@
   if (kind == svn_node_none)
     return out_of_date (full_path, eb->txn_name);
+ SVN_ERR (check_for_lock (full_path, eb, pool));
   /* Build a new dir baton for this directory */
   new_dirb = apr_pcalloc (pool, sizeof (*new_dirb));
   new_dirb->edit_baton = eb;
@@ -430,6 +452,8 @@
   if (base_revision < cr_rev)
     return out_of_date (full_path, eb->txn_name);
+ SVN_ERR (check_for_lock (full_path, eb, subpool));
   /* Build a new file baton */
   new_fb = apr_pcalloc (pool, sizeof (*new_fb));
   new_fb->edit_baton = eb;

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 26 05:20:51 2003

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.