I've noticed an inconsistent behavior with respect to auto-unlock during
file commits.
Let's say that I have a directory which may contain at least one locked
file:
% svn status this_dir
M this_dir/file1
K this_dir/file2
Now if I commit the directory, I would expect that the modified file gets
committed and any locked files would be unlocked. However, it completely
ignores the locked file. In order to get it to unlock the other file, I
have to do one of the following:
1. If the file is modified, it would be checked-in and unlocked.
2. I could explicitly commit that file:
% svn commit this_dir/file2
3. I could explicitly unlock that file.
The behavior here is counter to what is documented in the latest Subversion
Book 1.3 nightly:
" Notice that after the commit is finished, svn status shows that the lock
token is no longer present in working copy. This is the standard behavior of
svn commit: it walks the working copy (or list of targets, if you provide
such a list), and sends all lock tokens it encounters to the server as part
of the commit transaction. After the commit completes successfully, all of
the repository locks that were mentioned are released‹even on files that
weren't committed. The rationale here is to discourage users from being
sloppy about locking, or from holding locks for too long. For example,
suppose Harry were to haphazardly lock thirty files in a directory named
images, because he's unsure of which files he needs to change. He ends up
making changes to only four files. When he runs svn commit images, the
process would still release all thirty locks."
Is the documentation incorrect or is this behavior intentional?
-Steve
p.s. Any idea when a Subversion Book v1.4 will be available? :^)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 20 23:11:56 2006