Re: Lock non-existent to allow reserving a path
From: Thomas ┼kesson <thomas.akesson_at_simonsoft.se>
Date: Mon, 3 Mar 2014 09:55:49 +0100
Thanks Philip for sharing your insight into the lock mechanisms.
Sorry about the delay, wanted to find time to investigate.
On 24 feb 2014, at 19:56, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Thomas ┼kesson <thomas.akesson_at_simonsoft.se> writes:
As discussed else-thread, should likely be considered a bug. It is not useful for these use cases since it requires the file to already exist.
Yes, I think we would want to block a good number of operations. If using locks on added files one might very well have to unlock before performing certain operations.
I just noticed that revert does not have a switch to release the locks. Actually, when reverting it is very easy to accidentally leave locks behind. It might make sense to never allow a revert of locked files without specifying either "--unlock" or "--no-unlock".
Interesting point. I agree we would want a consistent behaviour.
Perhaps it would be an acceptable performance degradation to get a separate lock report when having locked added files in WC.
Yes it does. Verified with the patch in my first post.
This code is in fs_make_dir(..) in tree.c:
I can't see any reason to make a recursive check for locks when doing mkdir (does not matter now, when locking non-existent is not allowed). Should be a simple change. An mkdir does not carry the same implications as a move or rmdir (they must of course do recursive check).
Copy is more complicated.
svn mkdir wc1/A
svn cp wc2/B wc2/A
Copy also checks locks recursively for to_path. Not sure if that matters now (when locking non-existent is not allowed).
If allowing locking non-existent I personally think it would be fine to fail that copy if there are locks below (no change to current code). Otherwise we could investigate if the locks actually conflict with nodes in the copy-source.
> Should status on wc2 show the lock? If wc2 doesn't have an
Yes, preferably. Is 'svn stat -u' doing a report similar to update? No separate lock report? More or less the same challenges as removing broken locks during update.
Do we see any other reasons to start reporting added files during an update? I have been thinking about the move improvements but not yet identified any situation.
I have identified a situation related to sparse Working Copies where reporting the added file would improve the user experience. When adding a file to a dir, which due to depth settings doesn't contain all files, a subsequent update does not trigger a conflict. The commit does. Reporting the added file could reveal the conflict earlier.
I would be interested in finishing the patch with the scope of allowing locking non-existent paths using URL and enhancing svn import such that the locks can be used for creating new files in the repository (add switch to send in lock tokens). I will also investigate the feasibility of reporting these locks in 'svn stat -u'. Support in the Working Copy can be a separate task awaiting more interest in those use cases.
This is an archived mail posted to the Subversion Dev mailing list.