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
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
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
Great work, all round :)
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
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
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
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,
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
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
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
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
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
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
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
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
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://
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
18 matches
Mail list logo