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
Received on 2013-11-15 20:40:37 CET