On Nov 3, 2008, at 10:01, David L wrote:
> On Sun, Nov 2, 2008 at 9:39 PM, Ryan Schmidt wrote:
>
>>> If all users can ssh into the svn+ssh host and are all in the
>>> group svn,
>>> can't they do any of the evil things that you mentioned they
>>> could do
>>> with the file protocol? It doesn't seem like once they've logged
>>> into the
>>> svn+ssh host there is anything to prevent them from using to file
>>> protocol.
>>
>> That is true, unless you restrict them to only accessing the
>> repository (and
>> denying them shell access) as shown here:
>>
>> http://svnbook.red-bean.com/en/1.5/
>> svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks.fi
>> xedcmd
>
> Interesting. Thanks for that link. Do you happen to know if that
> can be safely combined with the ControlMaster trick? It seems
> like if you restrict ssh access to only allow the svnserve command,
> you might lose the ability to have a control master?
>
> If we haven't been doing that trick, is it any more dangerous
> to use the file protocol than svn+ssh? And by dangerous, I'm not
> referring to susceptibility to intentional tampering... I trust the
> small
> team of developers that have access this directory. For example,
> are there any simultaneous access susceptibilities with the file
> protocol to an NFS repository that don't exist with svn+ssh?
>
> To work around the speed problems we've been having with
> svn+ssh, I was considering a hybrid file protocol and svn+ssh
> like this... We export the svn repository directory as read only
> to our developer workstations. When people check out or
> update, they do so via the file protocol. Then, before commits,
> we svn switch to an svn+ssh protocol to a server secured as
> shown in the above link. This doesn't prevent evil developers
> from reading the code, but it seems like it does prevent them
> from messing with the repository. Does this sound reasonable?
> svn switch seems to be pretty fast especially when compared
> to 5 minute checkouts that we've been experiencing lately.
I don't know the answers to your questions, but "svn switch --
relocate" is essentially a client-side operation, so indeed it should
be as fast as your client can modify the repository path in its
working copy's .svn directories. It doesn't need to contact the
repository (other than perhaps to verify that the UUID of the
repository at the new URL is the same as that of the repository at
the old URL).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-03 23:28:22 CET