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

How should permissions be set in a shared workspace environment?

From: James Oltmans <joltmans_at_bolosystems.com>
Date: 2007-04-11 03:27:12 CEST

Hey all, I've got a unix question.


We're working in an environment where one or more developers will access
and work on code in the same repository. Yes, I know that's not standard
practice but we're dealing with some space limitations, developer
impatience (no one likes to wait 30 minutes to rebuild) and no good way
to only rebuild part of the working copy.

Anyway, the subversion problem we're having is that developer A connect
to his workspace, edits some files, checks them in and is happy.
Developer B connects to the same workspace, alters the same or different
files in the same directory that developer A edited files. Developer B
checks in his code and gets the following lovely error:

Sending foo/bar/FILE1

Transmitting file data .svn: Commit succeeded, but other errors follow:

svn: Error bumping revisions post-commit (details follow):

svn: In directory '/.../foo/bar'

svn: Error processing command 'committed' in '/.../foo/bar'

svn: Error replacing text-base of 'FILE1'

svn: Can't change perms of file /.../foo/bar/FILE1': Operation not

svn: Your commit message was left in a temporary file:

svn: '/.../foo/bar/svn-commit.tmp'


This leaves directory bar locked. Running svn cleanup can sometimes
resolve the problem unless another svn file is owned by Developer A. In
the case that it's not owned by A and cleanup works, Developer B must
subsequently run svn update to get the .svn directory up to date. This
usually results in files that were only changed once to be flagged as
merGed during the update because the repo version and the current
version are the same but the old text-base version is still in the old


We're running on Red Hat Enterprise Linux ES release 4 (Nahant Update 3)
with svn, version 1.4.0 (r21228)

All developers are part of groupA and all files are read/writable by the
group. However, our .svn dirs look like the following:

total 36

-r--r----- 1 DeveloperA groupA 232 Apr 10 18:57 all-wcprops

-r--r----- 1 DeveloperA groupA 58 Apr 10 12:58 dir-prop-base

-r--r----- 1 DeveloperA groupA 59 Apr 10 19:09 dir-props

-r--r----- 1 DeveloperA groupA 475 Apr 10 19:09 entries

-r--r----- 1 DeveloperA groupA 2 Apr 10 12:58 format

drwxrwx--- 2 DeveloperA groupA 4096 Apr 10 12:58 prop-base

drwxrwx--- 2 DeveloperA groupA 4096 Apr 10 12:58 props

drwxrwx--- 2 DeveloperA groupA 4096 Apr 10 12:58 text-base

drwxrwx--- 5 DeveloperA groupA 4096 Apr 10 19:09 tmp


Is there some default set of permissions that Subversion uses when
creating these files? How do I get around this permissions issue when
the files that are being denied access were created by Subversion?



James Oltmans
SCM Administrator

Bolo Systems, Inc.


Received on Wed Apr 11 03:26:40 2007

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