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

RE: File permission after update

From: Giulio Troccoli <Giulio.Troccoli_at_uk.linedata.com>
Date: Wed, 11 Jun 2008 14:44:25 +0100

>
 
 
Linedata Services (UK) Ltd
Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB
Registered in England and Wales No 3027851 VAT Reg No 778499447
 
-----Original Message-----
 

> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> Sent: 11 June 2008 14:01
> To: Giulio Troccoli
> Cc: users_at_subversion.tigris.org
> Subject: Re: File permission after update
>
> Giulio Troccoli wrote:
> > We use Subversion 1.4.4 on a Linux box with Apache. The user/group
that
> > runs apache is svn/svn, and umask for user svn is 000. We use a
common
> > WC to perform automatic merges. This WC is created once and then
updated
> > after every commit (in the post-commit hook)
> >
> > When I checked out the WC everything was fine: all files have rw
> > permission for everybody and all directories have rwx permission for
> > everybody.
> >
> > When I do an update however, and I have new directories, these are
added
> > with rwx permission for svn user only, and r permission for the
group
> > and everybody else. This is particularly true for the .svn
directories
> > too.
> >
> > The problem we're having is that when a user then tries to merge his
> > changes, the script they use makes use of the WC and then commits
from
> > there. However Subversion complains that it cannot access a ./lock
file
> > and the commit fails.
> >
> > I'm sorry I cannot provide a more precise explanation, but we had to
fix
> > the problem straight away (which means a simple chmod) to allow the
> > process to go through. Next time it happens I will make an effort
and
> > get more info.
> >
> > In the meantime, does anybody have any idea why this would happen?
Has
> > anybody experience something like this or similar?
>
> Subversion isn't designed to have a shared working copy. The best fix
> is to have a working copy for each user which will permit concurrent
> work. The particular problem you are having is most likely being
caused
> by new files taking the primary group of the logged in user and
> permissions based on his umask. You can fix that, but it's not the
> right fix for this situation.

I know that a shared WC is a bad idea. However, this is used for merging
purposes only, and the merging is done by a script. So it's a very
controlled process. That doesn't make it right, I know.

I forgot to say, sorry, that the user and group of the new
files/directories is correctly svn/svn (the user/group apache runs as).
I thought about changing the user/group for apache to svn/users, as
users is the group for all users, but I don't think that that would make
any difference and the permissions are correct only for the user svn,
not for the group.

Finally, the umask for all users is 002, so if Subversion used this to
set the permission I should have had the correct ones for the group too,
which I didn't.

Giulio

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-11 15:45:01 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.