Thomas Ã…kesson <thomas.akesson_at_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*
Received on 2014-02-24 19:56:45 CET