[
https://issues.apache.org/jira/browse/SVN-4797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16721291#comment-16721291
]
Sinus Pi commented on SVN-4797:
-------------------------------
As I suspected, the file is simply erased and recreated upon update, as
demonstrated here:
{noformat}
$ chmod 0124 foo
$ chown :grp2 foo
$ ls -al foo
---x-w-r-- 1 usr grp2 17 Dec 13 17:26 foo
^-^-^---- some ridiculous file modes, just as an example, and ownership
changed
$ svn up foo
Updating 'foo':
U foo
Updated to revision 103.
$ ls -al foo
-rw-rw-r-- 1 usr grp 10 Dec 14 06:28 foo
^^-^^-^---- file modes reset to the usual 664, ownership too{noformat}
I believe the file should get truncated, instead of being erased and recreated,
to preserve file permissions and ownership.
> Executable file modes are reset when updating a file with no svn:executable
> property
> ------------------------------------------------------------------------------------
>
> Key: SVN-4797
> URL: https://issues.apache.org/jira/browse/SVN-4797
> Project: Subversion
> Issue Type: Bug
> Components: cmdline client
> Affects Versions: 1.9.9
> Reporter: Sinus Pi
> Priority: Minor
>
> The command-line client resets +x flags on files it updates, if they lack an
> svn:executable flag.
> As demonstrated here:
> {noformat}
> $ echo Test file >foo
> $ svn add foo
> A foo
> $ svn commit foo -m test
> Adding foo
> Transmitting file data .done
> Committing transaction...
> Committed revision 101.
> $ ls -al foo
> -rw-rw-r-- 1 usr grp 10 Dec 13 17:24 foo
> $ chmod a+x foo
> $ ls -al foo
> -rwxrwxr-x 1 usr grp 10 Dec 13 17:24 foo
> ^--^--^--- file is executable as much as it can get.
> ... the file was edited and committed in a second working copy ...
> $ svn up foo
> Updating 'foo':
> U foo
> Updated to revision 102.
> $ ls -al foo
> -rw-rw-r-- 1 usr grp 17 Dec 13 17:26 foo
> ^--^--^--- file is executable no more.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)