Branko Čibej <brane <at> wandisco.com> writes:
>
>
> On 15.11.2013 20:30, Rick Varney wrote:
>
>
> 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.
>
>
> You're allowed to modify and commit changes to a file that has the
> svn:needs-lock property regardless of whether it's locked or not.
> svn:needs-lock is not a constraint, it's just a reminder.
I see. I was thinking of it as a constraint, because we had customized our
setup to prevent checking in unlocked files in our pre-commit hook script.
Unfortunately, this same method can't be used to customize the svn delete
behavior, because the local file deletion happens exclusively on the client
side. Only at commit time will the user be reminded there is an issue.
> "svn
> delete" is not, and should not be, special. FWIW, I've seen editors
> that automagically make a file writable if you start modifying it
> ...
> 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.
>
>
> It really depends on what you think "Unix rm" actually is. The
> unlink() or remove() functions don't care about permissions on the
> target, only that you have write permission on the parent directory.
It does not surprise me to hear that system functions don't care about file
permissions. The OS flavor I'm most familiar with is rhel5. Here is how
the interactive rm command behaves in this case:
$ ll foo.txt
-r--r----- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt
$ rm foo.txt
rm: remove write-protected regular file `foo.txt'? y
So while rm is perfectly capable of removing the read-only file in a
directory where I have write permissions, it politely asks first. I had
assumed the rm command behaves similarly on many flavors of Unix (as well as
Linux).
> Given that you can lock a deleted file, I really don't see a
> problem. If Subversion started prompting the user in such cases, the
> change in behaviour might break scripts for people who depend on the
> Unix-like delete behaviour, where file permissions don't matter but
> directory permissions do.
Your last point is hard to refute - it would be change in behavior, and
would mess up existing scripting that does not expect interactive prompts.
Maybe this behavior can be made optional, enabled via the configuration file?
Locking a deleted file will work in the end. It is just a little less
intuitive, in my my opinion.
Best regards,
Rick
Received on 2013-11-16 00:58:10 CET