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:07:28 2007