On 2/24/14, 8:30 AM, Thomas Åkesson wrote: > We would like to enhance the locking in Subversion to support use cases where > the user needs to ensure that added files will be possible to commit. There > are a couple of use cases: > > 1. Adding files that are dependencies to other files, where the reference > mechanism is cumbersome. Simple cases include XML files that reference > graphics or XIncludes (can be difficult to refactor after a conflict, > especially for non-technical users). More complex cases include file formats > that are not open and where references are difficult to manage, e.g. MS Word, > InDesign, certain modeling tools. > > 2. There is a standardized naming convention based on series. The next file > of a certain type should take the next available number. Then there is a race > condition btw different users; how quickly can they finish work and commit > after determining the next number and adding to WC. > > One mapping towards svn usage could be: > svn up > touch model0018.xml #or create the file with the software. > svn add model0018.xml > svn lock model0018.xml > # invest effort in the new file and potentially link to it from other files. > svn commit
Why does doing the following where the empty file is always immediately created not work for these use cases: svn up touch model0018.xml svn add model0018.xml svn ci -m'Create model0018.xml' svn lock model0018.xml Worst case senario for this seems to be the following. Alice and Bob are both about to make a new model file. They select the next appropriate filename model0018.xml. They both touch and add the file and then try to check it in. Alice succeeds, Bob gets a message telling him his commit is out of date because Alice won the race. Bob then repeats the steps from the top (including selecting the now next available filename). I'm guessing the answer comes down to user education difficulties. > 3. When there is other software support above svn, it also makes sense to > reserve a path via: > svn lock http://.../model0018.xml > Then performs a programmatic commit that ensures that the lock token is > supplied (or svn unlock URL if aborting). Or maybe I'm missing something since I don't think handling this would be difficult in software. > Current status: > > Svn does not allow locking non-existent paths. It is blocked both in > libsvn_fs_base/libsvn_fs_fs as well as in mod_dav_svn. In the same areas of > the code in fs comments say: > "While our locking implementation easily supports the locking of > nonexistent paths, we deliberately choose not to allow such madness." > > Given that we now present valid use-cases, it is reassuring that the authors > of the locking code said it "easily supports the locking of nonexistent > paths". > > Locking an added file fails using the command line client. > > In 1.6: svn: warning: W160042: LOCK request on '/svn/repo2/newfile.txt' > failed: 405 Method Not Allowed > > In 1.8: svn: E155010: The node '/Users/.../newfile.txt' was not found. Yes the existing implementations make this easy to do. But your suggested implementation is not the right path to go down. > There is also a question of how mod_dav_svn should handle "null-locks" when > communicating with generic Webdav clients. The WebDAV specification initially > proposed support for null-locks but in later revisions moved away from them. > I propose to keep the current zero-size-file concept for non-svn clients. > There is already a distinction btw svn and non-svn clients in that code, I > just tweaked it. Yes and RFC 4918 killed lock-null resources off for good reason. The whole thing was overly complicated, requiring a separate DB on the server side to track the non-existent paths it should pretend to exist. Even worse if you wanted to support DeltaV you had to keep track of which lock-null resources existed when forever. However, if you just created the empty file then all of this went away and there was nothing special to handle. So you can't do what you propose and be RFC4918 compliant. The RFC says that locks of non-existent files MUST create the file and removing the lock MUST not remove the file. If we really want to make the UI appear to support locking non-existent files we can. There are some issues to work through but I think making the backend support locking non-existent files is the wrong approach. I see two approaches to doing this: 1) Server supports creating the empty files for the client with the LOCK request like we do with auto-versioning clients. This presents problems with how the working copy finds out about the new empty file. Since otherwise the client will give an out of date error on commit and then the update will have a conflict. If we just change the server then old clients talking with such servers will suddenly have this problem. Which seems undesirable. 2) Have the client create, schedule and commit the new empty file and then issue the lock. Essentially doing the steps I presented above for the user automatically. This presents the following problems: a) How does the client know it needs to create the empty file before the lock? I'd guess the answer here is that we check if the path exists and try to create it. If the wc has the path as already versioned and committed, then just try to create the lock (so we fail if you're trying to lock something someone has deleted). b) Does the race condition between two clients trying to lock the same path present a problem? Consider that one client is slightly behind another such that it runs the check path just as the first client has finished creating the file and then the two LOCK requests race. I'm guessing we're not going to be happy if the client that created the new file loses that race? For one thing the commit message from creating the file might not make sense. I'm guessing this could be solved with extending the commit to support a way to lock a file iff the commit succeeds. Only newer servers would support this and we could decide to allow newer clients with older servers to lock non-existent files with the above mentioned known limitations or simply not allow it at all. It seems to me that 2) is the better approach to me.
