Hello.
(Tried with SVN r1297653)
Please, consider the following scenario:
We have a clean working copy at the latest revision (say, r1) with one file.
1. Set lock on a file file locally
wc$ svn lock file
......
2. Unset lock on the file remotely
wc$ svn unlock file:///url/for/file
......
As result the lock is broken
wc$ svn status -u file
B 1 file
Status against revision: 1
3. Let's update to the latest revision (r1) now.
wc$ svn update
Updating '.':
At revision 1.
wc$ svn status -u file
Status against revision: 1
So the lock is removed. Actually "notify" function of SVN was called only twice
for update start and
for update end (both for working copy path, none for path to the file).
Here's why it happens. update_editor.c , function "close_file". Notification
condition looks like
if (eb->notify_func && !fb->already_notified && fb->edited) {
...
}
fb->edited is false here because the update didn't change contents or
properties, so the notification
is not generated even though "lock_state" is not unchanged.
For SVN 1.6.9 the same condition looks like
if (((content_state != svn_wc_notify_state_unchanged) ||
(prop_state != svn_wc_notify_state_unchanged) ||
(lock_state != svn_wc_notify_lock_state_unchanged) ||
(fb->tree_conflicted))
&& eb->notify_func
/* Supress notifications for files within locally deleted trees,
we will have already raised a tree conflict notification.
### When is FB->PATH absolute? Will we ever use the wrong key? */
&& !in_deleted_tree(eb, fb->path, TRUE, pool))
that seems to be more reasonable with respect to "lock_state" processing.
So I propose to add (lock_state != svn_wc_notify_lock_state_unchanged)
condition somewhere to SVN
1.7 (maybe not only to close_file but to close_directory too).
