Thomas Åkesson <thomas.akes...@simonsoft.se> writes: > 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".
There is a way to create such locks at present: checkout, lock a file, delete the file or parent directory, commit with --no-unlock. We have a regression test for this: lock_tests.py:deleted_path_lock. (Possibly this behaviour could be considered a bug, perhaps 'commit --no-unlock' should remove the locks on deleted files, but implementing that would be hard.) > 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 working copy is likely to be the hard bit. Probably we would want to block operations that undo the add: revert, move, delete, etc. when the lock is present. Attempting to move/remove the lock automatically would make these non-network operations into network operations. I'm not sure exactly what behaviour would be acceptable here. Do we want to prevent people reverting without network access? Another tricky bit is how are update/status going to interact with these locks? I think we would want the behaviour to be similar to the current locks. So update will report if a lock gets broken/stolen and will remove the lock from the working copy. I think this requires update/status to start reporting added files to the server so that the server can report on the locks. That looks as if it will require protocol changes. It gets even more tricky with directories: svn mkdir wc1/A touch wc1/A/f svn add wc1/A/f svn lock wc1/A/f svn mkdir wc2/A The lock wc1/A/f will prevent the commit of wc2/A, or at least I think it will. Should status on wc2 show the lock? If wc2 doesn't have an added 'A' then the lock is of no interest, but when 'A' is added then the lock should be reported. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*