Lock non-existent to allow reserving a path

Hi,
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

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).

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.

Breakdown of changes:

1. Make mod_dav_svn and fs allow locking of non-existent paths. This part is mandatory and I am attaching a rough patch that demonstrates the feasibility. With this change, the use-case 3 can be supported.

This part is the most important for us, to enable our software to avoid race conditions btw users.

It can be discussed whether it should be possible to configure the server to disallow these locks. I don't think they do much harm and configurability makes testing more complex.

2. There are already functional tools to manage these locks (svnadmin lslocks/rmlocks/unlock and svn unlock URL). Are any improvements required? E.g. making svn lslocks available (remotely).

3. Make the Working Copy support svn lock after svn add. This also requires taking care of (or blocking) some combinations with move and switch.

The implementation of these parts might be dependent on whether there is wider interest in these use-cases.

Proposal:

We would like to develop a patch for this functionality, tests first. I believe we can do tests, libsvn_fs and mod_dav_svn changes. However, we might need some assistance with the changes to Working copy / command line client.

The attached patch contains test coverage for the server side changes. There is one test for WC (currently marked XFail) and a list of ideas for additional WC tests. The areas I feel are most complex are related to move and switch. I personally don't think there is a strong need to support the combination of lock nonexistent with move/switch (just ensure we block those combinations).

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.

Thanks,
Thomas Å.