[TSVN] Permission problem in shared working copy

I found the message below about this permission problem through
archives, so can't do proper quoting. However..

We got similar issue here. We have one copy shared between three
developers (and possibly more later). I know it's not the proper way,
but it works perfectly fine with the command line svn. Problem arises
when using TortoiseSVN through shared directory (Samba).

I know sharing same work copy should be avoided, but due the enviroment
and server (eg. due license and database connections), it's not possible
- which is why we use shared copy. It's impossible to us run either
locally or several copies of the enviroment and it would make developing
pain in the ass if you had to commit and then compile changes before
being able to testing the changes (or even to compile the changes).

Now.. each user connects to the Samba share with own account, which has
correct group permissions. All the .svn directories have correct
permissions, and they work just fine with the command line svn as I
said. You can actually commit with Tortoise just fine, except it can't
update the text-base files properly and asks to run cleanup.

The thing is, that the file itself are protected, you cannot even change
their permissions (through Samba they show as read-only), BUT as the
directory has group write permissions, the command line svn tool
actually removes the file and recreates it - which is allowed (you can
do this manually through Samba too). Tortoise seems to try to
overwrite/edit the text-base files which is not allowed (not even
through command line). So instead of overwrite/edit Tortoise should do
the same as the command line tool - delete and recreate the file. This
way it would be more compatible with the command line svn.

Jouni Airaksinen

--------------------------------------------------------------------

Ryan Kuester wrote:
> I have three users sharing a working copy on a network share. When a user

Here's your big mistake.
Don't share working copies between users! That negates the whole design
of every version control system out there I know, including Subversion.
The name already says it: working _copy_. Every user gets his/her own
_copy_ of the sourcecode to work on.

> different than the one who checked out the working copy commits, the
commit
> succeeds but errors follow when updating the working copy:
>
> Error replacing text-base of 'file'
> Can't set file 'path/.svn/text-base/file.svn-base' read-write: Access is
> denied.
>
> Obviously, the non-owner cannot change permissions.

Correct. And it would be a severe security leak if they could! Well, at
least on filesystems which support user rights.

> I figured this was related to the Subversion issue 1509, which is
supposed
> to be fixed in the latest versions. We're using TortoiseSVN 1.1.1, Build
> 1857 and svn 1.1.1 on the server side. Using the UNIX command line client
> directly on the server, I have no problems.

If you really want to do this, even though I can't imagine why someone
would actually do this:
Depending on what filesystem you use on that network share, you have to
set the working copy root folder to _always_ set the read and write
permissions on new and modified files to public, no matter what user
accesses the files there. Don't know exactly how you can do this though.

Stefan

-- 
-Jouni
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org