[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: Fri, 11 Jul 2008 21:14:54 -0400

On Fri, Jul 11, 2008 at 12:35, Rohan Joseph <rohanjoseph_at_gmail.com> wrote:
> But this still does not address the issue of speed, does it? I agree
> with the security part, but why is it so slow?

Quoting myself:

When you use Apache, the path-based authorization checks are performed
for each path as it's checked out.
http://svnbook.red-bean.com/en/1.4/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.pathauthzoff

If you're doing more work on the checkout action (checkout AND
security checks using HTTP, vs. checkout only using file://), and have
to make a connection to the server for each path/file, then it follows
that it will take longer.

> On Fri, Jul 11, 2008 at 6:27 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>> On Fri, Jul 11, 2008 at 00:40, Rohan Joseph <rohanjoseph_at_gmail.com> wrote:
>>> Thanks for the pointer on the weblink.Agreed, that it is a step
>>> backwards - but for the reason of speed. For some reason, every
>>> command that works on http:// is much much slower than the
>>> corresponding command run on file:/// . Even a simple command like svn
>>> list http:// displays results in jolts and breaks instead of the
>>> file:// method of access. If there is something I am missing about it,
>>> could you please point it out?
>>
>> When you use file://, there is zero security. When you use Apache, the
>> path-based authorization checks are performed for each path as it's
>> checked out. http://svnbook.red-bean.com/en/1.4/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.pathauthzoff
>>
>>> On Thu, Jul 10, 2008 at 4:52 PM, 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
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> Rohan Joseph
>>>
>>
>
>
>
> --
> Best Regards,
>
> Rohan Joseph
>

---------------------------------------------------------------------
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-12 03:15:26 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.