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

Isn't this where an integration branch will come into play. You can
either use the
trunk as an integration branch, or a real SVN branch. With it, only
merged, and
hence changed, code will be re-built? Unless that is NOT true with
UniData.

________________________________

        From: James Oltmans [mailto:joltmans@bolosystems.com]
        Sent: Wednesday, April 11, 2007 4:43 PM
        To: Matt Sickler
        Cc: users@subversion.tigris.org
        Subject: 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 23:24:16 2007