[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] Permission problem in shared working copy

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-05-31 18:55:54 CEST

Jouni Airaksinen wrote:
> 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).

Three and more devs working on the same working copy? No seriously, why
do you even need version control? Your data will be overwritten so often
that version control is completely useless.

> 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

- You don't need a license for TSVN nor for Subversion
- You also don't need a license to set up an apache server and
Subversion with it.
- You also don't need a license for svnserve (if you prever that
Subversion server)
- You don't even need more licenses if your users authenticate against a
windows domain when accessing the Subversion repository. They already
have a license to access the server, no need for additional licenses.

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

I first thought to not comment on this, but I couldn't resist:
you shouldn't commit and then compile but the other way around!

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

I guess your error tells you something about locked files? Simple
solution: tell your virus scanner to *not* scan the working copy.

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

Some basic information:
TSVN uses the Subversion API to do all Subversion related stuff. That
includes executing commands like update, commit, ...
So, whatever the CL client does, TSVN does as well!
I'm not sure if you really tried the CL client from the same Windows
machines you're using TSVN from. Because if the files show up as
readonly, then not even the CL client could do an update!

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue May 31 18:56:16 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.