[
https://issues.apache.org/jira/browse/SVN-4637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15350924#comment-15350924
]
Johan Corveleyn commented on SVN-4637:
--------------------------------------
I don't understand. I guess a possible scenario is:
* User starts editing file with svn:needs-lock (this file is read-only by
default after checkout).
* His IDE acquires a lock and the svn client makes the file writable
automatically (after lock has been acquired).
* User might decide to revert (whether or not he has actually edited the file).
But AFAIK revert won't unlock automatically, or would it?
As long as the user has the lock, the file should remain writable, no? I think
it's up to "svn unlock" to release the lock and then make the file read-only
again. Why should revert do this? Or does revert also do an automatic unlock?
But the main source of confusion is that this "local deviation from checkout
state" is not visible in 'status'. If revert then does something to these files
(and notifies about them) it is unexpected. So at least 'status' should show
something for those files, if that's a state change that can be reverted.
Anyway, right now I can see no reason for revert to make files writable (if
they were made read-only by the user). Read-only-ness is not a state that we
track, it can't be committed as a change. Based on the above scenario I guess
there might be some reason to make a writable file read-only again (if you had
taken the lock, but then decide to unlock again), but I don't understand why
'revert' should do this.
> 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)
