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

Re: Remote access and continuous integration

From: Andy Levy <andy.levy_at_gmail.com>
Date: Thu, 10 Jul 2008 17:52:23 -0400

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.

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-10 23:53:31 CEST

This is an archived mail posted to the Subversion Users mailing list.

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