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.
in svn:// and http:// you can use any svn library version you want and the
users can use whatever client versions they want. Upon connection, they
negotiate functionallity. If you use file://, then it's possible for your
client (acting as a server) to silently upgrade the repository. That's fine
if it's only you accessing the repo. However, if your co-worker has NOT
upgraded to the same svn client, then tey can no longer access it.
There's problably several other things that I can't think of off the top of
my head.
- Kevin
Received on 2008-07-11 01:00:56 CEST