Upgrade from 1.7.5 to 1.8.8 mod_dav_svn breaks

2014-04-22 Thread Tom Kielty
We have been using SVN with WebSVN for 7 years now. It is a non-SSL, hosted on a Windows 2008 R2 server behind Apache 2.2. Recently we looked into upgrading from SVN 1.7.5 with WebSVN 2.3.3 to SVN 1.8.8 and the same WebSVN 2.3.3. The SVN upgrade worked with no issues. I ran the svnadmin upgrade

TortoiseSVN, OPTIONS request on 'foo' failed: 501 Not Implemented

2014-04-22 Thread Carl Brewer
G'day, I have a SVN repository that runs through apache (2.4), that works fine 99% of the time, but I am seeing the error OPTIONS request on '/svn/hcc_wko' failed: 501 Not Implemented only on one windows 7 64 bit PC. This happens if I try to checkout, or if I grab a copy of a working checko

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Nico Kadel-Garcia
On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard wrote: > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig > wrote: > >> >> this topic was raised several times in the past - the answers range from >> "will be better/solved in the next version 1.7" or "it is due to ntfs vs >> ext3/4" or it's the AV,

Re: Extra blank line when using command line editor for commit message

2014-04-22 Thread Justin Mrkva
I see, that’s good to know. I’ll definitely set it up, it does make sense to strip whitespace. Not sure why that isn’t done by default. :) Now I just have to figure out if a dump/load will apply the hooks to to clean up old log messages that have trailing whitespace. Not a big deal in the scheme

Re: Extra blank line when using command line editor for commit message

2014-04-22 Thread Ryan Schmidt
On Apr 22, 2014, at 12:52, Justin Mrkva wrote: > On Apr 21, 2014, at 6:19 PM, Ryan Schmidt wrote: > >> Yes: install the log-police.py hook script in your repository. >> >> http://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/log-police.py > > That looks good at first, but this e

Re: Extra blank line when using command line editor for commit message

2014-04-22 Thread Justin Mrkva
That looks good at first, but this excerpt from the Subversion book explains why that’s a bad idea: While hook scripts can do almost anything, there is one dimension in which hook script authors should show restraint: do not modify a commit transaction using hook scripts. While it might be temp

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Mark Phippard
On Tue, Apr 22, 2014 at 10:37 AM, Florian Ludwig wrote: > > >> One thing I recall about 1.7, is that virtually none of the changes did >> anything that really sped up checkout. So that is probably the worst thing >> to be testing with. If all you care about is checkout, then there was >> really

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Florian Ludwig
> One thing I recall about 1.7, is that virtually none of the changes did > anything that really sped up checkout. So that is probably the worst thing > to be testing with. If all you care about is checkout, then there was > really little done in 1.7 or 1.8 to speed it up. Most of the big > perf

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Mark Phippard
On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig wrote: > this topic was raised several times in the past - the answers range from > "will be better/solved in the next version 1.7" or "it is due to ntfs vs > ext3/4" or it's the AV, network setup or the Windows file indexing > service. After disab

RE: Subversion Windows Performance compared to Linux

2014-04-22 Thread Grierson, David
Also for consideration in any comparison like this is whether or not a virus scanner is getting in the way at all. Obviously on Linux this isn't going to be happening but most Windows builds will have a virus scanner of some sort. Dg. -- David Grierson

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Johan Corveleyn
On Tue, Apr 22, 2014 at 2:55 PM, Florian Ludwig wrote: > >> >> From your numbers I deduce that the performance degradation can be >> attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux: >> * NTFS vs. ext4: roughly a factor 3 slower. >> * Windows 7 vs. Linux: roughly a factor 2.5 s

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Florian Ludwig
> From your numbers I deduce that the performance degradation can be > attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux: > * NTFS vs. ext4: roughly a factor 3 slower. > * Windows 7 vs. Linux: roughly a factor 2.5 slower. > You assume that the file operation performance of Windo

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Johan Corveleyn
On Wed, Apr 16, 2014 at 7:13 PM, Florian Ludwig wrote: > Hi, > > this topic was raised several times in the past - the answers range from > "will be better/solved in the next version 1.7" or "it is due to ntfs vs > ext3/4" or it's the AV, network setup or the Windows file indexing service. > After

Re: Subversion Windows Performance compared to Linux

2014-04-22 Thread Florian Ludwig
Hi, On Wed, Apr 16, 2014 at 7:33 PM, Andreas Stieger wrote: > Can you re-run with --quiet? > Using --quiet did not make a difference. ( I was piping the output to /dev/null or $null on windows so there was no output anyway. ) > Which version if SQLite is the GNU/Linux client running with? >