Paul,
Got back from Ops. We don't have anything "special" setup other than what
already been mentioned. Overall the defining metrics for commit performance
are: ssh vs https, rtt on the network path and "randomness" of the blobs going
up.
No magic params on our end. We have it tuned the max v
With autorevision set to 'on' and curl:
Reverence speed for boot drive to USB3 spinning platter 4TB thing:
paul@paul-HiBox:~$ time cp /home/paul/clientDir/seven
/media/paul/sg4t/sevenb
real 0m1.539s
Create a new 501MB file on Svn Server:
paul@paul-HiBox:~$ time curl -u paul:myPassword http://
Philip Martin writes:
> I've upgraded my JDK and it produced all these warnings.
There is a second class of warnings of the form:
WARNING: JNI local refs: 57, exceeds capacity: 56
These are generated in two places: JNIUtil::putErrorsInTrace() and
Java_org_apache_subversion_javahl_util_PropLi
phi...@apache.org writes:
> Author: philip
> Date: Thu Jul 6 20:56:14 2017
> New Revision: 1801108
>
> URL: http://svn.apache.org/viewvc?rev=1801108&view=rev
> Log:
> Add exception checks to some of the JavaHL native code to avoid JVM
> warnings about JNI problems of the form:
>
> WARNING in na
Johan Corveleyn writes:
>> On my machine:
>>
>> dd: 3.3 sec
>> svn commit: 37 sec
>> svnmucc commit: 26 sec
>> curl commit: 9.5 sec
> [ cc += Stefan Fuhrman, who might have some more ideas about this ]
>
> If your SVN server is version 1.9 with FSFS backend, your
On Thu, Jul 6, 2017 at 4:10 PM, Philip Martin wrote:
> Paul Hammant writes:
>
>> I'm making each revision with..
>>
>> dd if=/dev/zero bs=1M count=500 2>/dev/null >
>> path/to/file/under/versionControl.dat
>>
>> .. which is random enough to completely thwart delta analysis of the file.
>> T
Philip Martin writes:
> Paul Hammant writes:
>
>> I'm making each revision with..
>>
>> dd if=/dev/zero bs=1M count=500 2>/dev/null >
>> path/to/file/under/versionControl.dat
>>
>> .. which is random enough to completely thwart delta analysis of the file.
>> That's slow enough in itself, b
Paul Hammant writes:
> I'm making each revision with..
>
> dd if=/dev/zero bs=1M count=500 2>/dev/null >
> path/to/file/under/versionControl.dat
>
> .. which is random enough to completely thwart delta analysis of the file.
> That's slow enough in itself, but I'm only checking the time of t
Let me go do some digging with the Ops team-
On Thu, Jul 6, 2017 at 2:31 PM, Paul Hammant wrote:
> Jacek, Can you share any config settings for mod_dav that might be areas
> to experiment with ?
>
> And, yes, just because the file commit has no discernible deltas at all,
> doesn't mean that Svn
Jacek, Can you share any config settings for mod_dav that might be areas to
experiment with ?
And, yes, just because the file commit has no discernible deltas at all,
doesn't mean that Svn doesn't attempt to make its own determination. I
wasn't using .bin suffixes as it happens but I'll bet there
I'm making each revision with..
dd if=/dev/zero bs=1M count=500 2>/dev/null >
path/to/file/under/versionControl.dat
.. which is random enough to completely thwart delta analysis of the file.
That's slow enough in itself, but I'm only checking the time of the commit.
- Paul
On Thu, Jul 6,
We've say 2-3x speed decrease using HTTP vs SSH in our cloud. With SSH and
some tuning we are getting close to the IO rate on the end server of any
size. HTTP/mod_dav and RTT is usually the culprit in our cases, on a LAN
that issues collapses. Likely server side processing of the delta's?
-jacek
On 06.07.2017 13:54, Paul Hammant wrote:
> For something that's 500MB in size (random binary data) I'm
> experiencing commits taking
> 10x longer than a straight copy to the drive the Svn repo is on.
>
> Both timings are on the same Ubuntu 17.04 machine, with the boot drive
> being the starting
For something that's 500MB in size (random binary data) I'm experiencing
commits taking
10x longer than a straight copy to the drive the Svn repo is on.
Both timings are on the same Ubuntu 17.04 machine, with the boot drive
being the starting position of the 512MB file and a USB3 mounted 4TB
seaga
Great work, all round :)
On 06.07.2017 12:45, Paul Hammant wrote:
> Someone owns the consequential updates to Homebrew - right ?
>
> Ref:
> https://github.com/Homebrew/homebrew-core/blob/master/Formula/subversion.rb
> - Pull-Requests are the usual model, but there's easily room for
> duplicated effort, here.
I usually p
Someone owns the consequential updates to Homebrew - right ?
Ref:
https://github.com/Homebrew/homebrew-core/blob/master/Formula/subversion.rb
- Pull-Requests are the usual model, but there's easily room for
duplicated effort, here.
- Paul
I'm happy to announce the release of Apache Subversion 1.9.6.
Please choose the mirror closest to you by visiting:
http://subversion.apache.org/download.cgi#recommended-release
This release fixes a bug where a repository would fail to store two files
having identical SHA-1 checksums [1]. Fur
18 matches
Mail list logo