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.
Received on 2014-02-24 20:37:26 CET