Expected performance

[Naumenko, Roman]

Hello,

How fast would you expect svn checkout to be from a server like one below? 
Considering eveyrthing on the server functioning as expected.

Apache 2.2.3

128G mem
10G
FSFS is local storage.

Thanks,
--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Expected performance

[Naumenko, Roman]

On 2013/07/08 12:51 PM, Andy Levy wrote:
> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>  wrote:
>> Hello,
>>
>> How fast would you expect svn checkout to be from a server like one below? 
>> Considering eveyrthing on the server functioning as expected.
>>
>> Apache 2.2.3
>> 
>> 128G mem
>> 10G
>> FSFS is local storage.
> I don't see how this can be answered. There are too many variables to
> consider. I/O performance, revision history of the items you're
> checking out, how much data you're checking out, server CPU and I/O
> performance on the client end all come to mind.
>
> Do you have a specific performance concern?

There are certainly a lot of variables. I'm just trying to find out some 
baseline.

For example, on one of the other servers it takes 12-13 min to checkout 
repo with ~17000 files, total size 1.2G (with average speed 2MB/s).

Is it considered good, bad or total disaster in term of svn performance?

--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Expected performance

[Naumenko, Roman]

On 2013/07/08 2:06 PM, Thomas Harold wrote:
> On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
>> Hello,
>>
>> How fast would you expect svn checkout to be from a server like one
>> below? Considering eveyrthing on the server functioning as expected.
>>
> Our bottleneck is usually the CPU, but we're doing svn+ssh access.  So 
> I lean towards a few less but more powerful cores.
>
> The only time we thrash the disks is when doing the nightly hotcopy of 
> our repositories (total of about 110GB).

That box has more than enough CPUs (forty), cores are barely utilized.
How is the access over ssh can be configured? I thought it's only 
http(s) or svn proto.

--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Expected performance

[Naumenko, Roman]

On 2013/07/08 2:33 PM, Andy Levy wrote:
> On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
>  wrote:
>> On 2013/07/08 12:51 PM, Andy Levy wrote:
>>> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>>>  wrote:
>>>> Hello,
>>>>
>>>> How fast would you expect svn checkout to be from a server like one below? 
>>>> Considering eveyrthing on the server functioning as expected.
>>>>
>>>> Apache 2.2.3
>>>> 
>>>> 128G mem
>>>> 10G
>>>> FSFS is local storage.
>>> I don't see how this can be answered. There are too many variables to
>>> consider. I/O performance, revision history of the items you're
>>> checking out, how much data you're checking out, server CPU and I/O
>>> performance on the client end all come to mind.
>>>
>>> Do you have a specific performance concern?
>> There are certainly a lot of variables. I'm just trying to find out some
>> baseline.
>>
>> For example, on one of the other servers it takes 12-13 min to checkout
>> repo with ~17000 files, total size 1.2G (with average speed 2MB/s).
>>
>> Is it considered good, bad or total disaster in term of svn performance?
> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>
> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).

Thanks Andy.
Seems like 1.5-2MB/s for checkout speed is what expected and can be 
considered ok performance.
Can anybody else confirm?

--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Expected performance (svn+ssh)

[Naumenko, Roman]

On 2013/07/08 5:10 PM, Thomas Harold wrote:
> On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
>>
>> That box has more than enough CPUs (forty), cores are barely utilized.
>> How is the access over ssh can be configured? I thought it's only
>> http(s) or svn proto.
> http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls
>  
>
>
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
>  
>
>
> svn+ssh access has some upsides and downsides.  For us, it was simpler 
> to get up and running with it back in 2007 when we were still getting 
> our feet wet with SVN 1.4.  We weren't ready to muck around with 
> Apache httpd and SSL certificates to do https access to the repository.
>
> We grant access at the repository level via Linux file system 
> permissions.  This means that every user needs to have their own 
> system account and belong to Linux group that owns the repository.
>
> chown -R svn-group1 /var/svn/svn-repository1
> chmod -R 770 /var/svn/svn-repository1
> chmod -R g+s /var/svn/svn-repository1
>
> Where the 770 is some combination of, 770, 775, 755, 750, 700.
>
> 770 = owner read/write, group read/write, other none
> 750 = owner read/write, group read-only, other none
>
> To keep things sane, we do not set permission by hand, but edit a 
> script that can be re-run to fix permissions on the repositories. Most 
> of our repositories follow a set naming pattern, which makes it easier.
>
> The other advantage of svn+ssh is that it works well when using FSVS, 
> because you can edit ~/.ssh/config so that FSVS can login to the SVN 
> server automatically and push/pull configuration file changes.

Thank you, its interesting.

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Expected performance

[Naumenko, Roman]

On 2013/07/10 9:41 AM, Philip Martin wrote:
> "Naumenko, Roman"  writes:
>> That box has more than enough CPUs (forty), cores are barely utilized.
> Subversion's default cache configuration is very conservative.
> Increasing the cache size can reduce disk IO and improve performance:
>
> http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning

That's one of the options I was looking at. When I checked mem 
allocation on the server, it appeared that 85% was used as cache, I 
thought apache process would take advantage of OS caching by default.

--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Subversion compilation

[Naumenko, Roman]

Hi,

Is there something obvious missing during compilation for such error?

bash-3.2$ /home/userb/svn/bin/svn co http://svnserver/svn/repositoryA/ 
/tmp/repoA/
/home/userb/svn/bin/svn: symbol lookup error: 
/home/userb/svn/lib/libsvn_ra_neon-1.so.0: undefined symbol: ne_accept_207

Version was 1.7.9, compiled with the following options (it gnored 
--without-apache though).
./configure  --without-berkeley-db --without-apache --without-apxs 
--without-swig  --with-ssl --with-serf=/home/userb/local/serf   
--prefix=/home/userb/svn

I've added path to svn lib in LD
bash-3.2$ ldd /home/userb/svn/bin/svn | grep neon
libsvn_ra_neon-1.so.0 => /home/userb/svn/lib/libsvn_ra_neon-1.so.0 
(0x2b3846cff000)

serf was 0.7.2 and apr was 1.4.5

There is an older version of svn installed in the system, maybe that's the 
reason?

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Subversion compilation

[Naumenko, Roman]

On 2013/08/07 6:19 AM, Philip Martin wrote:
> Daniel Shahaf  writes:
>>> bash-3.2$ /home/userb/svn/bin/svn co http://svnserver/svn/repositoryA/ 
>>> /tmp/repoA/
>>> /home/userb/svn/bin/svn: symbol lookup error: 
>>> /home/userb/svn/lib/libsvn_ra_neon-1.so.0: undefined symbol: ne_accept_207
>>>
>>> Version was 1.7.9, compiled with the following options (it gnored 
>>> --without-apache though).
>>> ./configure  --without-berkeley-db --without-apache --without-apxs 
>>> --without-swig  --with-ssl --with-serf=/home/userb/local/serf   
>>> --prefix=/home/userb/svn
>>>
>>> I've added path to svn lib in LD
>>> bash-3.2$ ldd /home/userb/svn/bin/svn | grep neon
>>>  libsvn_ra_neon-1.so.0 => /home/userb/svn/lib/libsvn_ra_neon-1.so.0 
>>> (0x2b3846cff000)
>> It appears libneon itself is missing; compare:
>>
>> % ldd /usr/bin/svn | grep neon
>>  libsvn_ra_neon-1.so.1 => /usr/lib/libsvn_ra_neon-1.so.1 
>> (0x7f988087c000)
>>  libneon-gnutls.so.27 => /usr/lib/libneon-gnutls.so.27 
>> (0x7f987e7d7000)
> Perhaps neon is static?  I seem to recall that building neon defaults to
> static only unless there is an explict --enable-shared.
>>> serf was 0.7.2 and apr was 1.4.5
>> serf-0.7 is old, but anyway, things should just work if you use
>>
>>--config-option=servers:global:http-library=serf
>>
>> to your command line.
> That probably won't help since the linker is failing to load the linked
> library at program startup.  It might work if Subversion was configured
> with --enable-runtime-module-search.  It would be better to fix the
> libneon problem.
It was indeed absent neon lib (I thought it's part of svn and would be 
compiled by default).
No issues with neon excluded in ./configure (--without-neon).
Also I used serf 0.7.2 because this version was used in get-deps.sh for 
that particular svn version, I guess I can use the latest.

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Balancing and proxing

[Naumenko, Roman]

Hi,

I wanted to check if it's possible to configure subversion in 
master-slave mode with some sort of common URL on the proxy server or 
loadbalancer, so end users wouldn't bother with different names for 
slave/master/readonly and geolocal names.

Of course, it would be ideal if subversion nodes could just share a 
storage, so any sort of requests from a load balancer can processed by 
any node without need to replicate changes over network.

Right now it's something like this:

 rwro
https://svnm.ab.orghttps://svns.ab.org
 rw |  |r
  |  rw| 
redirect---> https://svnm.ab.org
   master-replication->   slave

Which means that users should be aware which name to use for commits and 
which for pulls (in case of mistake, the write request will be proxied 
transparently to master)

I'd like to do something like this, where LB or proxy takes care about 
request types and directs them accordingly (maybe with some specific 
svn-awareness).

https://svn.ab.org
 LB
   rw-- |  ro
 ||
 ||
master  -->   slave

Thanks,
--Roman
PS Not sure if text diagram will keep format.
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Balancing and proxing

[Naumenko, Roman]

On 2013/08/12 8:35 PM, Nico Kadel-Garcia wrote:
> Nico Kadel-Garcia
> Email: nka...@gmail.com
> Sent from iPhone
>
> On Aug 9, 2013, at 20:12, Roman Naumenko 
>
>> You mean this one (svn clustering)?
>> http://www.wandisco.com/get?f=documentation/datasheets/DataSheet-Clustering.pdf
>>
>> It doesn't look like it's a simple loadbalancing architecture with a shared 
>> storage for repositories.
> Right. Shared storage is very vulnerable to corrupting that single shared 
> back end. This seems to be a well thought out multi master setup, and should 
> be far more resilient for most environments.

I tend to agree, although such direction limits scalability and administration 
'kiss'-ness.

>> There is some replication and synchronization involved, automatic failover, 
>> etc.
>> Is anybody using it, what its like?
>>
>> --Roman
> I'm working from the public specs. I'm not a Subversion master in my current 
> workplace, so lack the 3 hosts needed to really test it put.

--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: Suggestion to change the name "Subversion"

[Naumenko, Roman]

On 2013/08/12 5:25 PM, Mauricio Tavares wrote:
> On Mon, Aug 12, 2013 at 4:57 PM, Glenn Holmer  wrote:
>> On 08/12/2013 03:51 PM, Greg Stein wrote:
>>> Apache Subversion actually started as "Inversion" around December
>>> 1999, or January 2000. It wasn't until April 2000, that we accepted
>>> "Subversion" as a rename. It had "version" in the name, and we *were*
>>> trying to subvert the CVS installations/community, so the name fit
>>> extremely well :-)
>>>
>>> It became "Apache Subversion" in February 2010.
>> Great story, thanks!
>Agreed. On the name change topic, I had a professor who would
> greet people with "heaveno" because he believed the traditional
> greeting had satanic connotations. His attempts to make us use that
> did not go very far...
http://lyrics.wikia.com/Andrew_Rannells:Hello! 

:)

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

AuthType Basic (with ext LDAP)

[Naumenko, Roman]

Hi,

There is a simple setup for svn users authentication on the server using 
LDAP.


 DAV svn
 SVNListParentPath on
 SVNParentPath /path_to_data
 SVNListParentPath on
 AuthzSVNAccessFile /path_to_accessfile/accfile

 AuthzLDAPAuthoritative off
 AuthType Basic
 AuthBasicProvider ldap
 AuthName "your login pls"
 AuthLDAPBindDN "blah-blah"
 AuthLDAPBindPassword "somepass"
 AuthLDAPURL "ldap://URL+DC?sub?(objectClass=*)"
 AuthzForceUsernameCase Lower
 Require valid-user

 CheckSpelling On


What I noticed is that svn server making a request for each svn URI or 
operation, which neither LDAP server likes nor users that could be 
waiting for their turn to be authenticated and see delays in svn server 
response.

Could somebody point me where the problem is?
I'd expect only one authentication request from the server when user 
presents himself first time (or after cache expires).

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: AuthType Basic (with ext LDAP)

[Naumenko, Roman]

On 2013/10/18 1:51 PM, Ben Reser wrote:
> On 10/18/13 10:01 AM, Naumenko, Roman wrote:
>> What I noticed is that svn server making a request for each svn URI or
>> operation, which neither LDAP server likes nor users that could be
>> waiting for their turn to be authenticated and see delays in svn server
>> response.
>>
>> Could somebody point me where the problem is?
>> I'd expect only one authentication request from the server when user
>> presents himself first time (or after cache expires).
> This is a feature.  It allows you to use Apache authentication setups that are
> path based like mod_authz_svn is.  In your case (and most users case) the only
> authentication handler that cares about the path is mod_authz_svn, in which
> case you can use the mod_dav_svn configuration directive "SVNPathAuthz
> short_circuit" which will prevent subrequests from being generated for
> additional paths that a request touches other than the path in the request URI
> and instead simply ask mod_authz_svn to process the path directly.  This will
> speed up your server by quite a bit since subrequests are slow as well as
> resolving your problem with LDAP.
Ben, thank you.
When short_circuit is enabled, then LDAP requests are not recorded any 
more in the debug log (except for initial request), so that what I was 
looking for. Great.

But there are still checks (or maybe this is just info log) against 
access-file for each path in repository.
Is it something expected or enabled somewhere by default?

[Fri Oct 18 15:35:52 2013] [info] [client 10.11.11.18] Access granted: 
'user1' REPORT /trunk/very_long_path/Data.manifest
[Fri Oct 18 15:35:52 2013] [debug] 
subversion/mod_authz_svn/mod_authz_svn.c(195): [client 10.11.11.18] Path 
to authz file is /path_to_access_file/svn_acc

I mean if a user has access to a repository, why checking all paths 
under? Or its just info log about mod_authz_svn processing path 
directly, as you said?

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

SVN server log

[Naumenko, Roman]

Hello,

Could somebody help me with what I see in the logs on the server?

In some cases subversion server logs each request during checkout (get-file or 
get-dir)

Like this:
11.11.11.71 - bob [22/Oct/2013:15:57:50 -0400] 207 1331 "SVN/1.7.13 serf/1.2.1" 
repo:benchmark-svn [get-file /big-tree/combined/zoom-in-7.icns r26 props] 1331 
Bytes in 0 Sec
11.11.11.71 - bob [22/Oct/2013:15:57:50 -0400] 207 1334 "SVN/1.7.13 serf/1.2.1" 
repo:benchmark-svn [get-file /big-tree/combined/edit-paste-4.icns r26 props] 
1334 Bytes in 0 Sec
11.11.11.71 - bob [22/Oct/2013:15:57:50 -0400] 207 1329 "SVN/1.7.13 serf/1.2.1" 
repo:benchmark-svn [get-file /big-tree/combined/lmarbles.icns r26 props] 1329 
Bytes in 0 Sec
11.11.11.71 - bob [22/Oct/2013:15:57:50 -0400] 207 1327 "SVN/1.7.13 serf/1.2.1" 
repo:benchmark-svn [get-file /big-tree/combined/gquilt.icns r26 props] 1327 
Bytes in 0 Sec

What I usually see is only one line in this log about checkout-export operation:
11.11.11.22 - bob [22/Oct/2013:15:27:39 -0400] 200 107392120 "SVN/1.8.3 
(i686-pc-cygwin) serf/1.3.1" repo:benchmark-svn [checkout-or-export / r33] 
107392120 Bytes in 354 Sec

(both were svn co, one with the client on cygwin, another with from Linux box 
using 1.7.13 with compiled serf).

Seems like this slows down checkouts somewhat, when client has to wait for a 
server to dump the loglines from buffer.

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Re: AuthType Basic (with ext LDAP)

[Naumenko, Roman]

On 2013/10/18 5:09 PM, Ben Reser wrote:

On 10/18/13 12:46 PM, Naumenko, Roman wrote:


But there are still checks (or maybe this is just info log) against
access-file for each path in repository.
Is it something expected or enabled somewhere by default?

[Fri Oct 18 15:35:52 2013] [info] [client 10.11.11.18] Access granted:
'user1' REPORT /trunk/very_long_path/Data.manifest
[Fri Oct 18 15:35:52 2013] [debug]
subversion/mod_authz_svn/mod_authz_svn.c(195): [client 10.11.11.18] Path
to authz file is /path_to_access_file/svn_acc

I mean if a user has access to a repository, why checking all paths
under? Or its just info log about mod_authz_svn processing path
directly, as you said?



The authz access file is only read once per connection.

But the checks will be run for each path accessed by the request.  Some of the
requests over HTTP actually access multiple paths in the repository.  For
instance a REPORT request might be doing what's referred to as a bulk update,
in which case it's asking for details on all the paths under a given path.  The
update REPORT in this case will include file content for paths under the path.
 Only the top level path will be in the URI.  If you want to disallow access to
some paths under that root path of the request it is necessary to check all the
paths.  Some other operations like COPY and MOVE also touch paths other than
the one in the URI for the request since the action requires two paths.

So what you're seeing is perfectly normal operation for the short_circuit
configuration.  You can entirely disable the additional checks mentioned above
by setting "SVNPathAuthz off".  However, I would not recommend that as it will
make some authz rules ineffective.  The whole created by this in the update
report case can be closed by also setting "SVNAllowBulkUpdate off" but that
doesn't help the COPY or MOVE cases.  So in general, there's really not a great
reason to use the off setting.


I'd like to thank you, Ben.
With short_circuit (and LDAP caching mentioned below in the thread), svn 
experience is much better.

--Roman
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.

Flatten out svnaccess

[Naumenko, Roman]

Hello SVN users,

We're looking to integrate svn access info into some reporting systems, but its 
almost impossible to use information from svnaccess to join with other sources.
The reason is that there are no structured relation between groups, users, 
repositories and permissions.

So I'm looking how to get it flattened, to have something like this:

user1 | group1 | repo | path | permissions
user2 | group1 | repo | path | permissions
and so on...

So far I managed to get first two cols, after massaging svnaccess file with 
combination of sed, grep and awk.
Then it become obvious that getting last three will be a problem.

Does anybody know if its possible to get this file transformed into something 
more sql friendly?

Thanks,
--Roman Naumenko
___

This email is intended only for the use of the individual(s) to whom it is 
addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in 
error, please advise immediately and delete the original message. 
This message may have been altered without your or our knowledge and the sender 
does not accept any liability for any errors or omissions in the message.

Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits 
et obligations qui s'y rapportent. 
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il 
contient par une personne autre que le (les) destinataire(s) désigné(s) est 
interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par 
retour de courriel ou par un autre moyen.