New - Support all-or-nothing mode when locking multiple files

http://subversion.tigris.org/issues/show_bug.cgi?id=2699

                 Issue #|2699
                 Summary|Support all-or-nothing mode when
locking multiple file
                        |s
               Component|subversion
                 Version|trunk
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|ENHANCEMENT
                Priority|P3
            Subcomponent|unknown
             Assigned to|issuessubversion
             Reported by|cmpilato






------- Additional comments from cmpilatotigris.org Fri Jan 19 08:34:27 -0800 2007 -------
The following question came from Eric Miller
<Eric.Milleramd.com>:

   Is there a way to get svn_client_lock to do an
all-or-nothing lock?
   Right now when it encounters an error during lock the
function gives
   a warning but keeps locking.

   For instance:

     user1% svn lock a
     user2% svn lock a b
     svn: warning: Path '/trunk/a' is already locked by user
'user1 in
filesystem '/svn/test/db'
     'b' locked by user 'user2.

   Is this a bug or intended behavior?   I can see this
being useful for
   collections of binary data.

Answers included this from me:

   Nope.  Locks aren't protected by atomicity guarantees
outside what is
   required to maintain the integrity of the backend
storage.  The
   repository APIs only permit locking one path at a time,
and no other
   layer of interface between client and repository
currently attempts to
   corral multiple path-lock attempts under the umbrella of
all-or-nothingness.

And this from Ben Collins-Sussman:

   Yeah, this use-case just didn't cross our minds when we
designed the
   feature.  It's certainly a feature that could be added in
the future,
   if there were enough demand.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2699







------- Additional comments from cmpilatotigris.org Fri Jan 19 08:37:15 -0800 2007 -------
I imagine it wouldn't be too terribly hard to implement
this.  New FS API
svn_fs_lock_many(), new repos wrapper API
svn_repos_fs_lock_many(), and I think
our RA layer already support sending multiple lock requests
across the wire at
once, so it would only need a flag that turns on the
"all-or-nothing guarantee",
and then some client-side UI to opt for that.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2699




User cmpilato changed the following:

                What    ld value 
               |New value
============================================================
====================
             Assigned to|issuessubversion        
|cmpilato
------------------------------------------------------------
--------------------
                     URL|                          |http://svn.collab.net/view

                        |                         
|vc/svn/branches/issue-2699
                        |                          |-dev
------------------------------------------------------------
--------------------




------- Additional comments from cmpilatotigris.org Fri Jan 19 09:09:35 -0800 2007 -------
Development effort for on this issue may be found on the
issue-2699-dev branch:
   SVN: http://svn.collab.net/repos/svn/branches/issue-2699-dev
   ViewVC: http://svn.collab.net/viewvc/svn/branches/issue-2699-dev



------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2699




User cmpilato changed the following:

                What    ld value 
               |New value
============================================================
====================
                  Status|NEW                       |STARTED
------------------------------------------------------------
--------------------




------- Additional comments from cmpilatotigris.org Fri Jan 19 09:09:52 -0800 2007 -------
STARTED.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2699







------- Additional comments from cmpilatotigris.org Tue Jan 30 08:16:32 -0800 2007 -------
See some list discussion about the FSFS side of this feature
at
htt
p://svn.haxx.se/dev/archive-2007-01/0708.shtml

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org

http://subversion.tigris.org/issues/show_bug.cgi?id=2699







------- Additional comments from cmpilatotigris.org Wed Mar 28 10:30:25 -0700 2007 -------
Okay, so, summarizing that list discussion about doing this
in FSFS:

   * should validate locks before taking out write lock

   * probably need to hold the write lock through the whole
of the operation,
     though there's concern about the amount of time for
which this would block
     other writers where many lock requests exist.

   * won't get isolation here, but maybe that's okay.

This doesn't make me feel especially happy.

I wonder (aloud) ... since locks are sorta outside the flow
of normal versioned
data, would it make sense to use a different mutex file in
FSFS for lock/unlock
operations?  That way lockers/unlockers could block other
lockers/unlockers, but
not committers.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org