You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Jeff Marver <jm...@serlio.com> on 2010/03/17 15:30:33 UTC
file:/// protocol based svn repository questions
Hi all,
We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:/// protocol based svn repositories on shared Windows network drives. Can anyone tell me the exact permissions a Windows user will need to fully interact with the repository? We're recently run into a user that was able to lock a file but couldn't do a commit, the error indicated that the commit failed and a .tmp file couldn't be moved since it already existed in txn-current? The customer indicated that they had read and write access??
Also, I've seen quite a few posts on the Internet suggesting that sharing a file:/// protocol based svn repository is not recommended for multiple users and even discouraged. Can anyone confirm or refute this information?
Thanks!
Jeff
RE: file:/// protocol based svn repository questions
Posted by Jeff Marver <jm...@serlio.com>.
Hi David,
Thanks for the info!
Regards,
Jeff Marver | Serlio Software Development Corporation | 414-771-1452 x224
Easily create great Use Cases and Requirements - www.casecomplete.com
-----Original Message-----
From: David Weintraub [mailto:qazwart@gmail.com]
Sent: Wednesday, March 17, 2010 4:57 PM
To: Jeff Marver
Cc: users@subversion.apache.org
Subject: Re: file:/// protocol based svn repository questions
You should NEVER use the file:// protocol unless you are the only
person using the repository, and the repository is only accessible by
you.
The file:// protocol requires read and write permissions on all files
in the repository for the user who is doing the committing. This means
that instead of using Subversion commands, the user can munge the
repository directly. For example, the user could copy the repository,
manipulate the items in it, and then replace it with the munged copy.
Even worse, if user "bob" does a commit, the version file is now owned
by "bob", and if the rights aren't setup correctly, only "bob" might
be able to read and write that version.
I don't know if there are concurrency issues, but I don't even use
file:// when I am creating my own temporary repositories.
I understand why you may not want to use Apache's http as your server.
That can be a bit of a bear to setup. However, the svnserve server is
quick and simple to setup. It is definitely easier to use than shared
Windows directories and affords you full client/server protection.
You should seriously consider not using the file:// protocol.
On Wed, Mar 17, 2010 at 11:30 AM, Jeff Marver <jm...@serlio.com> wrote:
> Hi all,
>
>
>
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??
>
>
>
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?
>
>
>
> Thanks!
>
>
>
> Jeff
--
David Weintraub
qazwart@gmail.com
Re: file:/// protocol based svn repository questions
Posted by David Weintraub <qa...@gmail.com>.
You should NEVER use the file:// protocol unless you are the only
person using the repository, and the repository is only accessible by
you.
The file:// protocol requires read and write permissions on all files
in the repository for the user who is doing the committing. This means
that instead of using Subversion commands, the user can munge the
repository directly. For example, the user could copy the repository,
manipulate the items in it, and then replace it with the munged copy.
Even worse, if user "bob" does a commit, the version file is now owned
by "bob", and if the rights aren't setup correctly, only "bob" might
be able to read and write that version.
I don't know if there are concurrency issues, but I don't even use
file:// when I am creating my own temporary repositories.
I understand why you may not want to use Apache's http as your server.
That can be a bit of a bear to setup. However, the svnserve server is
quick and simple to setup. It is definitely easier to use than shared
Windows directories and affords you full client/server protection.
You should seriously consider not using the file:// protocol.
On Wed, Mar 17, 2010 at 11:30 AM, Jeff Marver <jm...@serlio.com> wrote:
> Hi all,
>
>
>
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??
>
>
>
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?
>
>
>
> Thanks!
>
>
>
> Jeff
--
David Weintraub
qazwart@gmail.com
RE: file:/// protocol based svn repository questions
Posted by Jeff Marver <jm...@serlio.com>.
Hi Andy,
Thanks for the info!
Regards,
Jeff Marver | Serlio Software Development Corporation | 414-771-1452 x224
Easily create great Use Cases and Requirements - www.casecomplete.com
-----Original Message-----
From: Andy Levy [mailto:andy.levy@gmail.com]
Sent: Wednesday, March 17, 2010 10:47 AM
To: Jeff Marver
Cc: users@subversion.apache.org
Subject: Re: file:/// protocol based svn repository questions
On Wed, Mar 17, 2010 at 11:30, Jeff Marver <jm...@serlio.com> wrote:
> Hi all,
>
>
>
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??
Full control.
>
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?
Very bad idea. When you do this, anyone can corrupt or even delete the
whole repository with one errant keystroke. And you have no path-based
authorization. If someone uses a newer client with the repository,
older ones may not be able to read it. There /may/ be concurrency
concerns as well, but I'm not 100% sure on that.
Have a look at the final bullet point on
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.choosing.html
Set up a proper SVN server, you'll be much better off.
Re: file:/// protocol based svn repository questions
Posted by Andy Levy <an...@gmail.com>.
On Wed, Mar 17, 2010 at 11:30, Jeff Marver <jm...@serlio.com> wrote:
> Hi all,
>
>
>
> We're using SharpSVN.SvnRepositoryClient.CreateRepository to create file:///
> protocol based svn repositories on shared Windows network drives. Can anyone
> tell me the exact permissions a Windows user will need to fully interact
> with the repository? We're recently run into a user that was able to lock a
> file but couldn't do a commit, the error indicated that the commit failed
> and a .tmp file couldn't be moved since it already existed in txn-current?
> The customer indicated that they had read and write access??
Full control.
>
> Also, I've seen quite a few posts on the Internet suggesting that sharing a
> file:/// protocol based svn repository is not recommended for multiple users
> and even discouraged. Can anyone confirm or refute this information?
Very bad idea. When you do this, anyone can corrupt or even delete the
whole repository with one errant keystroke. And you have no path-based
authorization. If someone uses a newer client with the repository,
older ones may not be able to read it. There /may/ be concurrency
concerns as well, but I'm not 100% sure on that.
Have a look at the final bullet point on
http://svnbook.red-bean.com/en/1.5/svn.serverconfig.choosing.html
Set up a proper SVN server, you'll be much better off.