What about if the user uses TortoiseSVN over samba?
-----Original Message-----
From: Steve Bakke [mailto:steven.bakke@amd.com]
Sent: Wednesday, April 11, 2007 3:39 PM
To: James Oltmans; Matt Sickler
Cc: users@subversion.tigris.org
Subject: Re: How should permissions be set in a shared workspace environment?
On 4/11/07 4:42 PM, "James Oltmans" <joltmans@bolosystems.com> wrote:
> 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.
>
Using a shared working copy is definitely possible. (we are currently doing
just that) You need to make sure people's umask is set to be 2. That said,
the way that we enforce it is that the commandline client is wrapped in a
script which automatically sets the permissions to be user+group rwx for any
directories and rw for any files.
Obviously when users create new directories on their own, they still need to
set proper permissions. Just make sure that they source a standard shell
init script or something to make sure their umask is set.
-steve
>
>
> 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.
>
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 12 00:39:08 2007