[
https://issues.apache.org/jira/browse/SVN-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350952#comment-15350952
]
Bert Huijben commented on SVN-4637:
-----------------------------------
We don't handle read-only ness as a versioned attribute/property of the file,
but we have quite some code that tracks read-only-ness as part of locking.
A file that has svn:needs-lock and not locally locked is made read-only on
checkout, update, revert, commit, etc.
But now the svn:needs-lock property is removed locally, or remotely, but the in
wc file couldn't be changed. On Windows this could happen if another
application has it open with some incompatible share flags. And as the property
is now removed there is no way we can remember that something changed. (We
would need more that the pristine and current version of the property values in
this case to remember)
So now you have some read only file in your working copy...
For WC-NG we explicitly made 'svn revert' always revert your working copy match
how it would be after a clean checkout. (I think [~philipm]worked on this at
the time). And he did quite a bit more work to ensure that we always provide a
notification when we change the working copy. (Older versions could change your
working copy, but not notify you about this)
I don't think extending status to show that the local-read only state is
different than expected is really going to help anybody. Especially on
platforms where it is also common to have read flags mapped in a umask, so the
value could be different for different users looking at the same working copy.
I think it might have been better to use a specific notify for 'fixing
read-only-ness' during revert, but I'm not sure if this is really worth all the
backwards compatibility breakage to apply this three versions after this
behavior was introduced.
> 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)
