On Thu, Jul 10, 2008 at 18:59, Kevin Grover <kevin_at_kevingrover.net> wrote:
> On Thu, Jul 10, 2008 at 3:42 PM, Mark K <mark_at_mitsein.net> wrote:
>>
>> On Thu, 10 Jul 2008 17:52:23 -0400
>> "Andy Levy" <andy.levy_at_gmail.com> wrote:
>>
>> > On Thu, Jul 10, 2008 at 17:08, rjk1408 <rohanjoseph_at_gmail.com> wrote:
>> > >
>> > > Hi all,
>> > >
>> > > I have been looking through posts for answers to my
>> > > questions - found many similar threads, but nothing yet that is
>> > > nearly exact. My apologies for any repetition.
>> > >
>> > > 1. I have a svn repository setup on a server that resides locally
>> > > where I work. This repository is currently being accessed through
>> > > Apache.
>> > >
>> > > 2.I am developing a continuous integration system, whereby, the
>> > > entire process of merging and committing work to the repository
>> > > will be automated (tests need to be performed on a persons code
>> > > before it can be checked in etc.)
>> > >
>> > > 3. I wish to have a program running on a remote server (possibly a
>> > > daemon process), 1000 miles away, that will, at 11 pm every night,
>> > > checkout the trunk of the repository I mentioned in step 1.
>> > >
>> > > Question: How do I configure my repository such that
>> > >
>> > > a. The daemon process on the remote server reads and writes from my
>> > > repository through the http protocol through apache AND
>> > >
>> > > b. The developers working along with me, move to the file-system
>> > > access (file:///) method of accessing the local repository.
>> > >
>> >
>> > If you're currently using Apache for your human users (as opposed to
>> > the CI system you're writing), why take a step backwards in
>> > configurability and security by going to file:/// access?
>> >
>> > If you're sure this is the right thing to do (and I'm not convinced),
>> > The Manual provides information on supporting multiple access methods.
>> > http://svnbook.red-bean.com/en/1.4/svn.serverconfig.multimethod.html
>> >
>>
>> How is file:// access less secure or configureable than svn. svn+ssh,
>> or http type access?
>
> svn:// and http:// are both servers. There is a single process that manages
> all access to the repository. This simplifies file permissions and
> potential conflicts (the svn client library does manage several people
> trying to commit at the same time, simultaneous read access is not a
> problem). Mostly though, it allows it to set user and passwords. In
> file:// if you can write to the repository, you have access to commit to
> it. If you can read access you can read. There is not control of which
> users can read or commit (except for file/dir access permissions).
>
> If course, since you can write to the repository, you could cd in there and
> delete or manually edit files also, intentially or by accident, thus hosing
> individual revisions, or the entire repo. With svn:// and http:// the user
> (or his processes) never access the actual repo. With file:// the users
> client IS the server.
The "the client is the server" concept can also cause issues with hook
scripts. With a real server, hooks run on the server. With file://,
they run on the committer's workstation.
From http://svnbook.red-bean.com/en/1.4/svn.serverconfig.choosing.html#svn.serverconfig.choosing.recommendations:
"Do not be seduced by the simple idea of having all of your users
access a repository directly via file:// URLs. Even if the repository
is readily available to everyone via network share, this is a bad
idea. It removes any layers of protection between the users and the
repository: users can accidentally (or intentionally) corrupt the
repository database, it becomes hard to take the repository offline
for inspection or upgrade, and it can lead to a mess of
file-permissions problems"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-11 03:43:47 CEST