> On 24 feb 2014, at 20:36, Ben Reser <b...@reser.org> wrote: > >> 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.
No. I simplified the use cases, too much obviously. Let me try again: svn up for several hours: svn add a few files svn lock those files work, including linking to those files revise a bit review and perhaps svn unlock and svn rm some added files svn commit > >> 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. It becomes complicated when: - we might be talking about a few hundred files, and we would prefer not to commit them one by one (many reasons not to) - it is desirable to allow the user to review the end result before commit - I was not only talking about automated selection of file names, could be combinations of manual and series. - again, links btw the files Without a locking mechanism, we would basically need a layer of temporary naming and linking that is resolved when attempting to commit, and retried until a commit succeeds without conflict. If we don't have an open file format that we can manipulate, well forget it. > >> 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. Well, that is why I propose to stay compliant when talking to a generic webdav client. Lock-null would only be allowed with svn clients. There are other areas where svn clients are deviating from Webdav RFCs, right? > 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. None of these approaches address the use-cases when generalised, and these approaches can be accomplished with currently released svn. I probably over-simplified the use cases, sorry about that. I think use-case 1 does to some degree describe the complexity we would like to address. Regards, Thomas Å.
