On 2/22/2017 17:13, Carlos Adean wrote: > Hello, > > > ----- Mensagem original ----- >> De: "Stefan Hett" <ste...@egosoft.com> >> Para: users@subversion.apache.org >> Enviadas: Segunda-feira, 20 de fevereiro de 2017 12:03:36 >> Assunto: Re: .svn/wc.db as group writable >> >> On 2/20/2017 1:40 PM, Carlos Adean wrote: >> >> >> >> >> On the specific issue: I'm not getting completely what problem you >> are >> facing. Are you expecting that SVN sets the group for .svn/wc.db >> according to some group you set up by itself so it's readably/usable >> by >> other users than the one who did the repository checkout? >> >> Regards, >> Stefan >> >>> So, I have set umask 002 and it works for all files except on >>> .svn/wc.db - maybe I'm wrong and this is not a SVN problem. >>> >>> >>> Again, I know this is unusual situation but is how we need to work. >>> >>>> Can you be a bit more specific what exactly you mean by "That's the >>>> file that causes the problem[...]"? Do you get an SVN error when you >>>> perform some operation from different accounts on the working copy >>>> (in that case, please state the exact error message)? Alternatively: >>>> Are you suggesting that after performing an SVN operation the >>>> permissions of .svn/wc.db are changed (to what they were before the >>>> call)? > The default umask is 002 for all users and all of them are in the same group > 'appgroup', which is the group that owns the repositories. The repositories > are remote and one specific user creates local copies/clones. This user > checks out a repository in a given directory (e.g. > /home/appuser/software/trunk) using his own account. If a different user > tries to svn update the same local copy of the repository, he gets errors of > the type: > > svn: E155004: Working copy '/home/appuser/software/trunk' locked > svn: E200031: sqlite: attempt to write a readonly database > svn: E200031: sqlite: attempt to write a readonly database > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) > > my doubt is: if the umask is 002 why are the permissions for the group > read-only on that file after checkout? > It certainly looks like some permission setup on your environment to me. I don't have a test Linux machine running atm, so I can't test; but I'd assume that files created in the user's home directly by default are only granted full access by the current user, no? [1] Maybe someone who's more familiar with Linux permissions can pick this one up and provide you further details, if needed.
[1] http://unix.stackexchange.com/questions/95897/permissions-755-on-home-user Regards, Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
