Re: SVNSYNC Error

[Honeylyn O. Fukuoka]

Thanks so much for this info, Will try this and will let you know it it is
successful...



Thanks,


Honey

On Wed, Aug 1, 2012 at 2:36 PM, David Chapman  wrote:

> On 7/31/2012 11:16 PM, Honeylyn O. Fukuoka wrote:
>
>> Hi,
>>
>> The repositories and the destination repositories are all running on
>> windows.
>> Im not really an expert on batch files/shell script development...That's
>> why Im asking for your help :(
>> I just followed what I was told to do here but I don't want to mess
>> things up.
>>
>>
> Here are the commands I ran on a Windows machine to synchronize from a
> remote repository:
>
> svnadmin create c:\user\work\repos
> cd c:\user\work\repos\hooks
> echo exit 0 > pre-revprop-change.bat
> svnsync initialize file:///user/work/repos http://repos.sourcedomain.com/*
> *repos 
> svnsync sync file:///user/work/repos
>
> This ran just fine with SVN 1.6.  Can you run something similar on your
> Windows machine and let us know what results you get?  Run the steps in a
> new directory, not in the repository you just created. Note that the source
> repository in my example is served by Apache, so it uses a "http:" prefix.
> You would want to use a "svn:" prefix if you are using svnserve access, as
> was implied by your original message.
>
> Note that the destination repository is being accessed using the "file:"
> protocol.  The repository I created was not meant to be accessed by other
> users; it is intended only to serve as a backup. If you are trying to set
> up a write-through proxy then you will need something like svnserve or
> Apache HTTP on the destination repository.
>
> Also, depending on your repository directory names, you may need to use
> quote marks around arguments.  I recommend avoiding space characters in
> your directory names for this test.
>
>
> --
> David Chapman  dcchap...@acm.org
> Chapman Consulting -- San Jose, CA
> Software Development Done Right.
> www.chapman-consulting-sj.com
>
>


-- 
*HONEYLYN O. FUKUOKA*
System Administrator
Menue Philippines, Inc.
*
*

unsubscribe

[anubhav prabakar]

unsubscribe   

svnadmin dump & server shutdown

[Andreas Krey]

Hi everybody,

our sysdamins raised a question whether 'svnadmin dump' is safe to
run on a live repo (served via apache). The man page does not list a
requirement to stop other operations before dumping, but neither does
it go into any detail what happens if new revisions are created while
the dump is running. (Nor does the backup section in the book.)

So: is it safe to run 'svnadmin dump' on an operational repo, and will it
dump up to the last revision at the time of its start or its termination?

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: SVNSYNC Error

[Stefan Sperling]

On Wed, Aug 01, 2012 at 03:00:25PM +0800, Honeylyn O. Fukuoka wrote:
> Thanks so much for this info, Will try this and will let you know it it is
> successful...

There are quite a lot of posts in this thread already, and I'm surprised
that nobody seems to have pointed Honeylyn to the relevant section of the
svnbook: 
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication.svnsync

Please read this page first, and if you have any further questions,
*then* ask on this list.

If you're also going to set up a write-through proxy see
http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy

Good luck!

Re: SVNSYNC Error

[Honeylyn O. Fukuoka]

Hi,

Thanks for this.
We are using snserve not Apache...
Will this link still work with us?



Thanks,

Honey

On Wed, Aug 1, 2012 at 4:51 PM, Stefan Sperling  wrote:

> On Wed, Aug 01, 2012 at 03:00:25PM +0800, Honeylyn O. Fukuoka wrote:
> > Thanks so much for this info, Will try this and will let you know it it
> is
> > successful...
>
> There are quite a lot of posts in this thread already, and I'm surprised
> that nobody seems to have pointed Honeylyn to the relevant section of the
> svnbook:
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication.svnsync
>
> Please read this page first, and if you have any further questions,
> *then* ask on this list.
>
> If you're also going to set up a write-through proxy see
>
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy
>
> Good luck!
>



-- 
*HONEYLYN O. FUKUOKA*
System Administrator
Menue Philippines, Inc.
*
*

RE: SVNSYNC Error

[Cooke, Mark]

> From: Honeylyn O. Fukuoka [mailto:honey...@menue.com] 
> Sent: 01 August 2012 09:58
> To: Honeylyn O. Fukuoka; David Chapman; vishwajeet singh; 
> users@subversion.apache.org
> Subject: Re: SVNSYNC Error
> 
> Hi,
>  
> Thanks for this.
> We are using snserve not Apache...
> Will this link still work with us?

I don't want to be rude but perhaps you could have checked the links before 
posting this question?

~ mark c

> On Wed, Aug 1, 2012 at 4:51 PM, Stefan Sperling  wrote:
> 
> 
>   On Wed, Aug 01, 2012 at 03:00:25PM +0800, Honeylyn O. 
> Fukuoka wrote:
>   > Thanks so much for this info, Will try this and will 
> let you know it it is
>   > successful...
>   
>   
>   There are quite a lot of posts in this thread already, 
> and I'm surprised
>   that nobody seems to have pointed Honeylyn to the 
> relevant section of the
>   svnbook: 
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#s
> vn.reposadmin.maint.replication.svnsync
>   
>   Please read this page first, and if you have any 
> further questions,
>   *then* ask on this list.
>   
>   If you're also going to set up a write-through proxy see
>   
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html
> #svn.serverconfig.httpd.extra.writethruproxy
>   
>   Good luck!
>   
> 
> 
> 
> 
> -- 
> HONEYLYN O. FUKUOKA
> System Administrator
> Menue Philippines, Inc.
> 
> 
> 
> 
> 

Re: SVNSYNC Error

[Stefan Sperling]

On Wed, Aug 01, 2012 at 04:57:57PM +0800, Honeylyn O. Fukuoka wrote:
> Hi,
> 
> Thanks for this.
> We are using snserve not Apache...
> Will this link still work with us?

Sure. svnsync is just about repository replication, and has nothing
to do with what server is being used to allow access to the repository
via the network.

You didn't mention why you want to use svnsync. If your goal is to back
up a repository to another machine then all you need is svnsync.
If the goal is to set up a write-through proxy using the mirrored repostory
then you need svnsync and Apache HTTPD because svnserve doesn't support
write-through proxying.

Re: svnadmin dump & server shutdown

[Philip Martin]

Andreas Krey  writes:

> So: is it safe to run 'svnadmin dump' on an operational repo, and will it
> dump up to the last revision at the time of its start or its termination?

Yes, it is safe to run on live repository.  If the admin doesn't specify
a revision range it will default to 0:HEAD where HEAD is determined
before starting the dump.  If you change revision properties during the
dump and those changes occur after the revision involved has been dumped
then the dump will include the old, rather than new, values.

-- 
Philip

Re: SVNSYNC Error

[Andy Levy]

On Wed, Aug 1, 2012 at 4:57 AM, Honeylyn O. Fukuoka  wrote:
> Hi,
>
> Thanks for this.
> We are using snserve not Apache...
> Will this link still work with us?

Yes (please read the links to the documentation you've been provided).
But not with an HTTP URL for your source repository. If you're using
svnserve, your URL should be svn://

>
> On Wed, Aug 1, 2012 at 4:51 PM, Stefan Sperling  wrote:
>>
>> On Wed, Aug 01, 2012 at 03:00:25PM +0800, Honeylyn O. Fukuoka wrote:
>> > Thanks so much for this info, Will try this and will let you know it it
>> > is
>> > successful...
>>
>> There are quite a lot of posts in this thread already, and I'm surprised
>> that nobody seems to have pointed Honeylyn to the relevant section of the
>> svnbook:
>> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication.svnsync
>>
>> Please read this page first, and if you have any further questions,
>> *then* ask on this list.
>>
>> If you're also going to set up a write-through proxy see
>>
>> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy
>>
>> Good luck!
>
>
>
>
> --
> HONEYLYN O. FUKUOKA
> System Administrator
> Menue Philippines, Inc.
>
>

Re: SVNSYNC Error

[Honeylyn O. Fukuoka]

Hi,

The reason why I am doing the svnsync is to backup our repository to our
new server in our main branch.


Thanks,


Honey

On Wed, Aug 1, 2012 at 5:14 PM, Stefan Sperling  wrote:

> On Wed, Aug 01, 2012 at 04:57:57PM +0800, Honeylyn O. Fukuoka wrote:
> > Hi,
> >
> > Thanks for this.
> > We are using snserve not Apache...
> > Will this link still work with us?
>
> Sure. svnsync is just about repository replication, and has nothing
> to do with what server is being used to allow access to the repository
> via the network.
>
> You didn't mention why you want to use svnsync. If your goal is to back
> up a repository to another machine then all you need is svnsync.
> If the goal is to set up a write-through proxy using the mirrored repostory
> then you need svnsync and Apache HTTPD because svnserve doesn't support
> write-through proxying.
>



-- 
*HONEYLYN O. FUKUOKA*
System Administrator
Menue Philippines, Inc.
*
*

Re: SVNSYNC Error

[Honeylyn O. Fukuoka]

Hi,

I tried the one in your link under repository replication and followed what
was instructed there.
I also changed the pre-revprop-change hook script based on the example
given there and so as the start-commit hook.
But when I performed the 'svnsync initialize' command, I got this error:
 svnsync: E170001: Authorization Failed

Here are the scripts I put in the pre-revprop-change hook
#!/bin/sh

USER="$3"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Only the syncuser user may change revision properties" >&2
exit 1
And for the start-commit hook:
#!/bin/sh

USER="$2"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Only the syncuser user may commit new revisions" >&2
exit 1

Those are exactly the same scripts that was on the book.
I also did what David told me to do, to create another pre-revprop-change
hook script with 'exit 0' and save it in .bat but also received the same
error.

Can anyone tell me what should I do to succesfuly erform the initialize
command?



Thanks so much,


Honey

On Wed, Aug 1, 2012 at 5:59 PM, Andy Levy  wrote:

> On Wed, Aug 1, 2012 at 4:57 AM, Honeylyn O. Fukuoka 
> wrote:
> > Hi,
> >
> > Thanks for this.
> > We are using snserve not Apache...
> > Will this link still work with us?
>
> Yes (please read the links to the documentation you've been provided).
> But not with an HTTP URL for your source repository. If you're using
> svnserve, your URL should be svn://
>
> >
> > On Wed, Aug 1, 2012 at 4:51 PM, Stefan Sperling  wrote:
> >>
> >> On Wed, Aug 01, 2012 at 03:00:25PM +0800, Honeylyn O. Fukuoka wrote:
> >> > Thanks so much for this info, Will try this and will let you know it
> it
> >> > is
> >> > successful...
> >>
> >> There are quite a lot of posts in this thread already, and I'm surprised
> >> that nobody seems to have pointed Honeylyn to the relevant section of
> the
> >> svnbook:
> >>
> http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication.svnsync
> >>
> >> Please read this page first, and if you have any further questions,
> >> *then* ask on this list.
> >>
> >> If you're also going to set up a write-through proxy see
> >>
> >>
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy
> >>
> >> Good luck!
> >
> >
> >
> >
> > --
> > HONEYLYN O. FUKUOKA
> > System Administrator
> > Menue Philippines, Inc.
> >
> >
>



-- 
*HONEYLYN O. FUKUOKA*
System Administrator
Menue Philippines, Inc.
*
*

RE: SVNSYNC Error

[Cooke, Mark]

> On Wed, Aug 1, 2012 at 5:14 PM, Stefan Sperling  wrote:
> 
> 
>   On Wed, Aug 01, 2012 at 04:57:57PM +0800, Honeylyn O. 
> Fukuoka wrote:
>   > Hi,
>   >
>   > Thanks for this.
>   > We are using snserve not Apache...
>   > Will this link still work with us?
>   
>   
>   Sure. svnsync is just about repository replication, and 
> has nothing
>   to do with what server is being used to allow access to 
> the repository
>   via the network.
>   
>   You didn't mention why you want to use svnsync. If your 
> goal is to back
>   up a repository to another machine then all you need is svnsync.
>   If the goal is to set up a write-through proxy using 
> the mirrored repostory
>   then you need svnsync and Apache HTTPD because svnserve 
> doesn't support
>   write-through proxying.
>   
> -Original Message-
> From: Honeylyn O. Fukuoka [mailto:honey...@menue.com] 
> Sent: 01 August 2012 13:15
> To: Honeylyn O. Fukuoka; David Chapman; vishwajeet singh; 
> users@subversion.apache.org
> Subject: Re: SVNSYNC Error
> 
> Hi,
>  
> The reason why I am doing the svnsync is to backup our 
> repository to our new server in our main branch.

If all you are doing is a one-off move, then you should also investigate using 
dump/load.  Depending on the size of your repo this can take a while, but can 
be done without svnsync and can have advantages in having your shiny new in the 
latest format.

I suggest that you read the manual, especially this bit about "Migrating 
Repository Data Elsewhere":-

http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate

~ mark c

P.S. It is often good to explain what you are trying to do before asking for 
specific help.  This helps us to discuss other, better ways to do stuff than 
you know about...

Repairing or removing broken revisions

[Joachim Sauer]

Hello,

I'm currently reworking backups of multiple SVN repositories. In the
process I found out that one of those repositories has three broken
revisions. The problem is that the revision files in the revs
directory for those 3 revisions are of size 0 (those contain the
actual data of the revision, as far as I understand). This means that
I can't use svn dump (as it stops at that broken revision) and I can't
use svnsync.

For the backup itself I can still use svn hotcopy (the previous way of
doing a backup), so this will be my workaround.

I was able to find out the affected paths in the repository and
luckily the latest revision of those paths can be checked out without
a problem (so we "only" lost history, not current data).

But a broken repository is not desirable and I should attempt to fix
it as much as possible. Losing the information of those three
revisions (and a few related ones, probably) would not be a major
problem, but the repository as a whole should be in a consistent state
(to allow svnadmin dump to work, for example).

Is there a way to remove the broken revisions and still keep the rest
of the repository intact? Ideally without requiring everyone to make
new clean checkouts because the repository became incompatible.

regards
Joachim Sauer

P.S.: unfortunately there are no working backups of the broken
revisions, as the corruption seems to be pretty old (older than our
last full backup).

Re: SVNSYNC Error

[Thorsten Schöning]

Guten Tag Honeylyn O. Fukuoka,
am Mittwoch, 1. August 2012 um 14:25 schrieben Sie:

> I also changed the pre-revprop-change hook script based on the example
> given there and so as the start-commit hook.

pre-revprop-change is enough, start with the easiest setup possible.

> But when I performed the 'svnsync initialize' command, I got this error:
>  svnsync: E170001: Authorization Failed

This has nothing to do with hooks, I suspect you provided wrong user
credentials to the source repo. Check that the provided user on the
command line is the same as stated in passwd file of the source repo.

> Here are the scripts I put in the pre-revprop-change hook
> #!/bin/sh

I'm rude now, but please concentrate on your problem! I only had a
fast look over the messages in this thread and found more than one
message telling you that hooks starting with #!/bin/sh are for Linux,
not for Windows. They won't work, don't do that, ignore each and every
hook starting with that line. It's wasted time, confuses you and even
the people who try to help you. You want to sync either to Windows or
Linux, I read Windows and therefore you won't need to do anything
starting with #!/bin/sh.

Please delete those files you created and simply forget about them.
:-)


> Those are exactly the same scripts that was on the book.

But the book has a paragraph noticing that one has to adopt the
procedure on Windows on it's own.

> I also did what David told me to do, to create another pre-revprop-change
> hook script with 'exit 0' and save it in .bat but also received the same
> error.

Because you don't even get where the hook could be used. But the
creation of this and only this one hook is fine and what you need.
Only this hook with the line "exit 0" as pre-revprop-change.bat.

> Can anyone tell me what should I do to succesfuly erform the initialize
> command?

Check the login credentials for the source and maybe even the
destination repo, depedning on how you access the destination. Provide
us the exact command line you ran for initialize, just without
passwords of course.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon.030-2 1001-310
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Repairing or removing broken revisions

[Johan Corveleyn]

On Wed, Aug 1, 2012 at 2:24 PM, Joachim Sauer  wrote:
> Hello,
>
> I'm currently reworking backups of multiple SVN repositories. In the
> process I found out that one of those repositories has three broken
> revisions. The problem is that the revision files in the revs
> directory for those 3 revisions are of size 0 (those contain the
> actual data of the revision, as far as I understand). This means that
> I can't use svn dump (as it stops at that broken revision) and I can't
> use svnsync.
>
> For the backup itself I can still use svn hotcopy (the previous way of
> doing a backup), so this will be my workaround.
>
> I was able to find out the affected paths in the repository and
> luckily the latest revision of those paths can be checked out without
> a problem (so we "only" lost history, not current data).
>
> But a broken repository is not desirable and I should attempt to fix
> it as much as possible. Losing the information of those three
> revisions (and a few related ones, probably) would not be a major
> problem, but the repository as a whole should be in a consistent state
> (to allow svnadmin dump to work, for example).
>
> Is there a way to remove the broken revisions and still keep the rest
> of the repository intact? Ideally without requiring everyone to make
> new clean checkouts because the repository became incompatible.
>
> regards
> Joachim Sauer
>
> P.S.: unfortunately there are no working backups of the broken
> revisions, as the corruption seems to be pretty old (older than our
> last full backup).

Since you know the affected paths, I think one possible way is to do
an svnsync, while excluding the "corrupted paths" by way of path-based
authz (i.e. make the affected paths unreadable by the svnsync user,
using an authz file on the source repository). After that, re-import
the "corrupted files" from one of your working copies.

I think everyone will have to re-checkout though, because you'll have
a new repository with slightly altered history. So it wouldn't be safe
to give this new repository the same repos-uuid, and act like it's the
same.

If you search the mailinglist archives, you might find some more posts
about this svnsync recovery trick (excluding broken files).

-- 
Johan

Re: Subversion authentication via SASL GSSAPI and likewise open

[Johan Corveleyn]

On Wed, Aug 1, 2012 at 7:04 AM, slaventii  wrote:
> My last test results :
> SVN Server:
> Ubuntu 12.04
> svn, version 1.7.5 (r1336830) compiled Jul 19 2012, 21:53:29
> SVN Client:
> Windows Server 2003
> svn, version 1.7.5 (r1336830) compiled May 15 2012, 12:29:08
> LAN 100 Mbit/s
>
> co svn:// ~ 37m 44 sec
> co https:// ~ 40m 04sec
> co svn vs https perf, % ~ > 6%
>
> up svn:// ~ 0m 35sec
> up https:// ~ 0m 19 sec
> up svn vs https perf, % ~ > 23%

Huh? How do you arrive at 23 %? According to these numbers, https is
almost twice as fast here.

> svn client 1.5.4 with svn server 1.7.5 with same servers:
> co svn:// - 22m 30 sec
>
> cat /etc/apache2/mods-enabled/dav_svn.conf
> 
>   # Enable a 1 Gb Subversion data cache for both fulltext and deltas.
>   SVNInMemoryCacheSize 1048576
>   SVNCacheTextDeltas On
>   SVNCacheFullTexts On
>   SVNCompressionLevel 0
>   SVNAdvertiseV2Protocol On
> 
>
> cat /etc/xinetd.d/svnserve
>server_args = -i -r /var/svn/repos
> --log-file=/var/log/svn/svn.log --memory-cache-size=1024
> --cache-txdeltas=yes --cache-fulltexts=yes --compression=0
>
> In my result I see that co operation decrised very high when I used new 
> client.
> Also co operation time has no so big difference between svn and http 
> protocols,
> But up operation is 23 % slower via http.
>
> Maybe this is because of "SVNCompressionLevel 0" ?
> "For example, on a local area network (LAN) with 1-Gigabit
> connections, it might not make sense to have the server compress its
> network transmissions (which also forces the clients to decompress
> them), as the network itself is so fast that users won't really
> benefit from the smaller overall network payload. On the other hand,
> servers which are accessed primarily by clients with low-bandwidth
> connections would be doing those clients a favor by minimizing the
> overall size of its network communications."
> But my LAN is 100 Mbit/s

That could very well be the reason here why your tests with 1.7 server
are slower. I suppose it's reasonable to expect that
SVNCompressionLevel 0 makes checkout slower on a 100 Mbit connection.
On a 1 Gbit connection the situation could be different, and it might
make it faster because CPU (for compression) might become the
bottleneck.

It might be interesting to repeat your tests with 1.7 server with a
default SVNCompressionLevel (which would then be the same compression
as your older server).

Some tests with the same hardware/software combinations over a 1 Gbit
connection might also be very interesting, but I suppose it'll be hard
for you to set up this environment.

-- 
Johan

Re: Subversion authentication via SASL GSSAPI and likewise open

[slaventii]

> Huh? How do you arrive at 23 %? According to these numbers, https is
> almost twice as fast here.
>
Sorry for mistake. Should be:
up svn:// ~ 0m 19sec
up https:// ~ 0m 35 sec
up svn vs https perf, % ~ > 23%

> That could very well be the reason here why your tests with 1.7 server
> are slower. I suppose it's reasonable to expect that
> SVNCompressionLevel 0 makes checkout slower on a 100 Mbit connection.
> On a 1 Gbit connection the situation could be different, and it might
> make it faster because CPU (for compression) might become the
> bottleneck.
>
> It might be interesting to repeat your tests with 1.7 server with a
> default SVNCompressionLevel (which would then be the same compression
> as your older server).

As I know compression appeared only in svn 1.7 and a didn't make any
setup with compression level in svn 1.5.3 and 1.6.17.
"Subversion 1.7 offers the --compression (-c) option to svnserve and
the SVNCompressionLevel directive for mod_dav_svn. Both accept a value
which is an integer between 0 and 9 (inclusive), where 9 offers the
best compression of wire data, and 0 disables compression altogether."

I done some tests with compression=9, but by my mistake it was with client 1.5.4
Will try again with client 1.7.4 and default compression=5 and max=9.

First test result:
co https:// - 39m 17sec - compression level =9

cat /etc/apache2/mods-enabled/dav_svn.conf

  # Enable a 1 Gb Subversion data cache for both fulltext and deltas.
  SVNInMemoryCacheSize 1048576
  SVNCacheTextDeltas On
  SVNCacheFullTexts On
  SVNCompressionLevel 9
  SVNAdvertiseV2Protocol On


>
> Some tests with the same hardware/software combinations over a 1 Gbit
> connection might also be very interesting, but I suppose it'll be hard
> for you to set up this environment.

You are right, but is possible. When I have more free time.

Re: Subversion authentication via SASL GSSAPI and likewise open

[Johan Corveleyn]

On Wed, Aug 1, 2012 at 9:56 PM, slaventii  wrote:
>> Huh? How do you arrive at 23 %? According to these numbers, https is
>> almost twice as fast here.
>>
> Sorry for mistake. Should be:
> up svn:// ~ 0m 19sec
> up https:// ~ 0m 35 sec
> up svn vs https perf, % ~ > 23%

Okay, got it.

>> That could very well be the reason here why your tests with 1.7 server
>> are slower. I suppose it's reasonable to expect that
>> SVNCompressionLevel 0 makes checkout slower on a 100 Mbit connection.
>> On a 1 Gbit connection the situation could be different, and it might
>> make it faster because CPU (for compression) might become the
>> bottleneck.
>>
>> It might be interesting to repeat your tests with 1.7 server with a
>> default SVNCompressionLevel (which would then be the same compression
>> as your older server).
>
> As I know compression appeared only in svn 1.7 and a didn't make any
> setup with compression level in svn 1.5.3 and 1.6.17.
> "Subversion 1.7 offers the --compression (-c) option to svnserve and
> the SVNCompressionLevel directive for mod_dav_svn. Both accept a value
> which is an integer between 0 and 9 (inclusive), where 9 offers the
> best compression of wire data, and 0 disables compression altogether."

If I understand correctly, the older versions of svn ( < 1.7) always
did wire-compression, but it wasn't configurable (probably with the
default compression level, i.e. 5). In 1.7 the configuration knob was
exposed so you can now manually tweak the desired compression level
(to save on CPU at the expense of some more wire-overhead). To get the
same behavior as with older versions, you can just omit the
configuration parameter, and it will still use the default of 5.

I don't know a lot of the details, but I seem to remember that the
wire-compression doesn't really buy you much, because the actual data
(the delta's that are transferred during checkout or update) is
already compressed. So it made sense to be able to disable that part
of the compression.

> I done some tests with compression=9, but by my mistake it was with client 
> 1.5.4
> Will try again with client 1.7.4 and default compression=5 and max=9.
>
> First test result:
> co https:// - 39m 17sec - compression level =9

Okay, please try again also with compression level = 5 (or just
without the configuration directive, that should be the same).

I'm getting a bit confused now between all the tests you did (checkout
was almost twice as fast with the 1.5 client against 1.7 server as
with the 1.7 client against the same server?? If that's true, we might
need to know more about the client system (e.g. on which filesystem
are you creating the working copy). Or was it with the older 1.5
server that svn:// was a lot faster?).

It might be better to start a new thread (with appropriate subject,
because this thread isn't really about "Subversion authentication via
SASL GSSAPI" anymore), with a new overview of the tests you did.

Also, be careful with the caching effects of the 1.7 server: a second
run against the same data will usually be a lot faster because all the
fulltexts will be cached in memory. So maybe you should run the test a
couple of times, ignore the first run, and then take the average of
the other runs (or if you want to test the "cold" performance, disable
the fulltext caching and/or restart the server process between each
run or something like that).

> cat /etc/apache2/mods-enabled/dav_svn.conf
> 
>   # Enable a 1 Gb Subversion data cache for both fulltext and deltas.
>   SVNInMemoryCacheSize 1048576
>   SVNCacheTextDeltas On
>   SVNCacheFullTexts On
>   SVNCompressionLevel 9
>   SVNAdvertiseV2Protocol On
> 
>
>>
>> Some tests with the same hardware/software combinations over a 1 Gbit
>> connection might also be very interesting, but I suppose it'll be hard
>> for you to set up this environment.
>
> You are right, but is possible. When I have more free time.

Cool, that would be awesome :-).

-- 
Johan

Re: Subversion authentication via SASL GSSAPI and likewise open

[Johan Corveleyn]

On Wed, Aug 1, 2012 at 10:50 PM, Johan Corveleyn  wrote:
> On Wed, Aug 1, 2012 at 9:56 PM, slaventii  wrote:
>>> Huh? How do you arrive at 23 %? According to these numbers, https is
>>> almost twice as fast here.
>>>
>> Sorry for mistake. Should be:
>> up svn:// ~ 0m 19sec
>> up https:// ~ 0m 35 sec
>> up svn vs https perf, % ~ > 23%
>
> Okay, got it.

Oh, and it just occurred to me: I assume your https test is with the
neon http library (the default up until now). Can you also try those
tests with the serf library (if that's compiled into your client)? To
do that, adding the following option to your command line should work:

--config-option servers:global:http-library=serf

Beware: there are still some (known) problems when using the serf
library in some environments (e.g. [1]), so you may or may not be able
to run those tests successfully. Either way, it would be interesting
to know ...

[1] http://subversion.tigris.org/issues/show_bug.cgi?id=4174 - serf:
checkout / export errors out with "svn: E730053: Error retrieving
REPORT (730053)"

-- 
Johan

Re: Subversion authentication via SASL GSSAPI and likewise open

[Daniel Shahaf]

Johan Corveleyn wrote on Wed, Aug 01, 2012 at 22:56:52 +0200:
> On Wed, Aug 1, 2012 at 10:50 PM, Johan Corveleyn  wrote:
> > On Wed, Aug 1, 2012 at 9:56 PM, slaventii  wrote:
> >>> Huh? How do you arrive at 23 %? According to these numbers, https is
> >>> almost twice as fast here.
> >>>
> >> Sorry for mistake. Should be:
> >> up svn:// ~ 0m 19sec
> >> up https:// ~ 0m 35 sec
> >> up svn vs https perf, % ~ > 23%
> >
> > Okay, got it.
> 
> Oh, and it just occurred to me: I assume your https test is with the
> neon http library (the default up until now). Can you also try those
> tests with the serf library (if that's compiled into your client)? To
> do that, adding the following option to your command line should work:
> 
> --config-option servers:global:http-library=serf

Only if serf has been enabled at build time:

svn --version | grep serf