Branko Čibej <brane <at> wandisco.com> writes: > I disagree with the behaviour change because it makes 'svn delete' in > the presence of svn:needs-lock behave exactly opposite to every other > command. IMO, it's quite enough to simply fix the bug where we try to > change the permissions on a non-existent local path. > > So I suggest you file a bug for that, not for the behaviour change.
In general I understand the point about behavior consistency, and I agree this is important. By behave opposite you mean that if 'svn delete' changes its behavior in the presence of svn:needs-lock, this would be opposite of other commands that ignore whether it is present? My suggestion is not to look for the presence of svn:needs-lock, but to honor file permissions when doing 'svn delete', irrespective of whether svn:needs-lock is set. I think there would be symmetry between this behavior and how svn currently handles file permissions: svn makes files with svn:needs-lock present read-only if no lock is set, so users that try to edit the file notice it is read-only, and take appropriate action - get the lock. In the same way, if 'svn delete' warned about or refused to delete read-only files, the user would be reminded to get the lock. This behavior is similar to how the unix rm command behaves. I think this would be more intuitive. > > > We won't fix this in 1.6 and 1.8 is already fixed: > > $ svn rm wc/A/f > D wc/A/f > $ svn st wc/A/f > D wc/A/f > $ svn lock wc/A/f > 'f' locked by user 'pm'. > $ svn st wc/A/f > D K wc/A/f > > > > Yes, I was just going to say. I added test cases for this on > trunk, and they passed; I've just been running them on 1.8, where > they pass as well. > In other words, upgrading to 1.8 will fix the issue, and in the > meantime, ask your users to either revert the delete first (i.e., > 'svn revert file; svn lock file; svn rm file; svn commit', or to > use the URL in the 'svn lock' command. > > > And here's the related issue:http://subversion.tigris.org/issues/show_bug.cgi?id=4304 Good - I agree the error message on lock/unlock is a bug, and it is good to know that it is now fixed. Best regards, Rick
