[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Svn revert and file permissions bug

From: Captain Hypertext <captainhypertext_at_gmail.com>
Date: Thu, 13 Aug 2020 09:29:56 -0400

I have a really weird problem which may be a bug.

I'm running Debian 9 with svn 1.8.17, but I also tried with svn 1.9.5,
which I guess is the latest version supported by our OS. Basically, I'm
tasked with updating the permission structure of our application servers
because we've been using root for years to do everything. We have an svn
repo where all the files are owned by the root user.

If I change the file ownership (I'm talking about the working copy files)
to apache:devops, so owned by user apache and group devops, and I run "svn
revert -R .", it lists out every single file. Nothing changes, it just says
"Reverted xxx.php" for every file, every time I run it. Run "svn revert -R
." again, same thing happens. None of the files have changed at all, and
root has write permissions. If there are local changes in the working copy,
they will be reverted along with all this.

This appears to be happening when svn thinks that my user doesn't have
write permissions to the file. It looks like svn is trying to calculate the
permissions of the files by itself, and isn't factoring in root powers, ACL
(setfacl), or supplemental user groups. So if I set a file's permissions to
666 instead of 664, it doesn't get spit out as reverted. Also, if my user
owns the file (this applies to root too) or my primary group owns the file,
it doesn't spit that file out. But being that a second group I’m a member
of owns the file, it gets spit out.

Can anyone speak to this? Any help is appreciated.

Jeremy
Received on 2020-08-13 15:31:56 CEST

This is an archived mail posted to the Subversion Users mailing list.