[
https://issues.apache.org/jira/browse/SVN-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350980#comment-15350980
]
Johan Corveleyn commented on SVN-4637:
--------------------------------------
Okay I see. If the svn:needs-lock was removed by someone else, but 'update'
could not make the file writable (even though it has successfully removed the
property), I can see how you can end up with a read-only file that svn had
intended to make writable. And there is no way for svn to know this later when
it encounters a read-only file (the "incompleteness" of the
svn:needs-lock-removal is not tracked, and it can't be reconstructed with local
information).
BTW: this does mean that users have no real control over read-onlyness in their
working copies. All files have to be writable, unless they have svn:needs-lock,
in which case they have to be read-only (unless you have the lock). Otherwise,
they might get reset by 'revert'. That's a bit unexpected.
I think specific notifications by revert would definitely be an improvement, to
avoid confusion and fear of having lost data unintentionally. But I'm not going
to pursue this further myself. I hope this issue is already a bit discoverable
so users can at least find an explanation for this behaviour.
> Revert affects unchanged files with changed permissions
> -------------------------------------------------------
>
> Key: SVN-4637
> URL: https://issues.apache.org/jira/browse/SVN-4637
> Project: Subversion
> Issue Type: Bug
> Affects Versions: 1.9.3
> Reporter: Johan Corveleyn
>
> If you make a file read-only, and run a recursive revert, the file is made
> writable again, and revert notifies:
> {noformat}
> C:\Temp\svntest>svnadmin create repos
> C:\Temp\svntest>svn co file:///c:/Temp/svntest/repos wc
> Checked out revision 0.
> C:\Temp\svntest>cd wc
> C:\Temp\svntest\wc>echo This is file 1 > file1.txt
> C:\Temp\svntest\wc>svn add *.txt
> A file1.txt
> C:\Temp\svntest\wc>svn ci -mm
> Adding file1.txt
> Transmitting file data ..done
> Committing transaction...
> Committed revision 1.
> C:\Temp\svntest\wc>attrib +R file1.txt ### (making read-only)
> C:\Temp\svntest\wc>svn st
> C:\Temp\svntest\wc>svn revert -R .
> Reverted 'file1.txt'
> {noformat}
> After this, the file is writable again.
> I think 'revert' should not affect files that have only metadata (like
> permissions) changed. I'm actually wondering how revert decided to do this,
> because I thought it acted on the result of a 'status walk', and 'svn status'
> does not show such a file.
> I'm not sure what revert should do with the modified permissions if it's
> already reverting the content.
> See also this post on users@:
> http://svn.haxx.se/users/archive-2016-03/0035.shtml
> The original post that started the thread:
> http://svn.haxx.se/users/archive-2016-03/0004.shtml
> OP reported this for Centos 6.5 Linux, so I suppose the issue is not limited
> to Windows.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
