RE: How should permissions be set in a shared workspace environment?

We realize it is not the best idea and that by using individual
workspaces we would automatically avoid this problem. However, we have
other problems that make the individual workspaces solution a very
unattractive option at this time.

We have tried giving them their own copies. They did not like the 20-30
mins rebuild turnaround time (we do not have a quick-build option, we
are working with UniData, not C++ or Java) and the fact that any time
they wanted to see a project team-member's contribution they needed to
rebuild. We also managed to fill up the hard drive on the server pretty
quickly with 2.5 gig a pop workspaces.

Given these challenges we would prefer to use a shared workspace. If you
know for certain this is not possible, that is an acceptable answer;
otherwise we'd like to know if anyone has experience with doing things
"the wrong way" with a shared workspace.

________________________________

From: Matt Sickler [mailto:crazyfordynamite@gmail.com]
Sent: Wednesday, April 11, 2007 2:07 PM
To: James Oltmans
Cc: users@subversion.tigris.org
Subject: Re: How should permissions be set in a shared workspace
environment?

its normal for several devs to work on the same _repository_ but having
more than one per _working copy_ is a very bad idea
at least try to get each one their own copy and problems like this are
automatically avoided

On 4/10/07, James Oltmans <joltmans@bolosystems.com> wrote:

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
permitted

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
state.

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?

Thanks!

James Oltmans
SCM Administrator

Bolo Systems, Inc.

 
Received on Wed Apr 11 22:43:13 2007