Re: Expected speed of commit over HTTP?

[Paul Hammant]

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://192.168.1.178/svn/
svnRepo1/twoB --upload-file /home/paul/clientDir/seven
201 Created
real 0m49.442s

*I ran that a couple more times and it was up there at 50s*


Needlessly overwrite 501MB file (file is unchanged) on Svn Server:


paul@paul-HiBox:~$ time curl -u paul:myPassword  http://192.168.1.178/svn/
svnRepo1/twoB --upload-file /home/paul/clientDir/seven
real 0m13.426s

Change the compression-level=0

paul@paul-HiBox:~$ sudo nano /media/paul/sg4t/svnParent/
svnRepo1/db/fsfs.conf

Create a new 501MB file on Svn Server:


paul@paul-HiBox:~$ time curl -u paul:myPassword  http://192.168.1.178/svn/
svnRepo1/twoC --upload-file /home/paul/clientDir/seven
201 Created
real 0m15.312s

Yay - a modest speed boost!!!


Restart Apache - which I didn't do before:


paul@paul-HiBox:~$ systemctl restart apache2

Create a new 501MB file on Svn Server:


paul@paul-HiBox:~$ time curl -u paul:myPassword  http://192.168.1.178/svn/
svnRepo1/twoD --upload-file /home/paul/clientDir/seven
201 Created
real 0m14.925s


Conclusion:

With compression-level=5 (default), there's is a 1:33 cp to curl-PUT ratio.
With compression-level=0, there's is a 1:10 cp to curl-PUT ratio.


Is there there are other alluring settings, such as...

enable-rep-sharing = false
enable-dir-deltification = false

... but they didn't yield an improvement.

Thanks for all the replies, gang.

-  Paul

Re: svn commit: r1801108 - in /subversion/trunk/subversion/bindings/javahl/native: Array.cpp CreateJ.cpp Iterator.cpp OperationContext.cpp RemoteSession.cpp RevisionRangeList.cpp

[Philip Martin]

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_PropLib_unparseExternals().

I'm not sure how best to fix these so I have a local hack in
JNIUtil::wrappedCreateClientException to remove most of them:

   // Create a local frame for our references
-  env->PushLocalFrame(LOCAL_FRAME_SIZE);
+  env->PushLocalFrame(LOCAL_FRAME_SIZE + 100);

-- 
Philip

Re: svn commit: r1801108 - in /subversion/trunk/subversion/bindings/javahl/native: Array.cpp CreateJ.cpp Iterator.cpp OperationContext.cpp RemoteSession.cpp RevisionRangeList.cpp

[Philip Martin]

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=rev
> Log:
> Add exception checks to some of the JavaHL native code to avoid JVM
> warnings about JNI problems of the form:
>
>   WARNING in native method: JNI call made without checking exceptions when 
> required to
>  

I've upgraded my JDK and it produced all these warnings.  I'm not sure
of the rules for JNI exception checking, take Iterator.cpp for example.
The call to JNIUtil::getInv() in Iterator::next() needs to be checked or
the warning is generated:

  jobject Iterator::next() const
  {
if (!m_jiterator)
  return NULL;

JNIEnv* env = JNIUtil::getEnv();
if (JNIUtil::isJavaExceptionThrown())
  return NULL;

static jmethodID next_mid = 0;

however similar code in Iterator::hasNext() doesn't need the check, at
least as far as the warning is concerned:

  bool Iterator::hasNext() const
  {
if (!m_jiterator)
  return false;

JNIEnv* env = JNIUtil::getEnv();

static jmethodID hasNext_mid = 0;

Both functions are used by the testsuite but only Iterator::next()
causes the warning.  Is Iterator::hasNext() correct to omit the check or
is this a limitation of the warning system?  Should all calls to
JNIUtil::getEnv() be checked?

-- 
Philip

Re: Expected speed of commit over HTTP?

[Philip Martin]

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 could try if
> the setting "compression-level" in the deltification section in
> $REPOS/db/fsfs.conf makes a difference:

Good idea!

With compression-level=0

   dd:  3.2 sec
   svn commit: 26   sec
   svnmucc commit: 16   sec
  curl commit:  3.9 sec

-- 
Philip

Re: Expected speed of commit over HTTP?

[Johan Corveleyn]

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.
>> That's slow enough in itself, but I'm only checking the time of the commit.
>
> The standard client always sends deltas even for cases like yours where
> the delta is not really an advantage. On receiving the delta the server
> has to first reconstruct the full text and then construct a second delta
> to store in the repository.
>
> You can make commits a bit faster by using svnmucc without a working
> copy, the svnmucc client always sends a delta against an empty file
> which is faster to calculate than the standard client delta against the
> previous file contents:
>
>   svnmucc put some/file URL
>
> You can make commits even faster by enabling SVNAutoversioning on the
> server and using curl as your client as then the client doesn't
> calculate delta at all:
>
>   curl -XPUT @some/file URL
>
> The curl commit will still involve calculating a delta on the server.
>
> 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 could try if
the setting "compression-level" in the deltification section in
$REPOS/db/fsfs.conf makes a difference:

[[[
### After deltification, we compress the data through zlib to minimize on-
### disk size.  That can be an expensive and ineffective process.  This
### setting controls the usage of zlib in future revisions.
### Revisions with highly compressible data in them may shrink in size
### if the setting is increased but may take much longer to commit.  The
### time taken to uncompress that data again is widely independent of the
### compression level.
### Compression will be ineffective if the incoming content is already
### highly compressed.  In that case, disabling the compression entirely
### will speed up commits as well as reading the data.  Repositories with
### many small compressible files (source code) but also a high percentage
### of large incompressible ones (artwork) may benefit from compression
### levels lowered to e.g. 1.
### Valid values are 0 to 9 with 9 providing the highest compression ratio
### and 0 disabling it altogether.
### The default value is 5.
# compression-level = 5
]]]

There is also the mod_dav_svn config directive SVNCompressionLevel [1]
and the client-side option http-compression [2] which you can try ...
don't know if those are a significant factor in your case.

[1] http://svnbook.red-bean.com/en/1.7/svn.ref.mod_dav_svn.conf.html

[2] see your ~/.subversion/servers file, or you can specify it for a
single command with an option:
--config-option servers:global:http-compression=no

-- 
Johan

Re: Expected speed of commit over HTTP?

[Philip Martin]

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, but I'm only checking the time of the commit.
>
> The standard client always sends deltas even for cases like yours where

I'm assuming /dev/urandom as /dev/zero doesn't really make sense here.

-- 
Philip

Re: Expected speed of commit over HTTP?

[Philip Martin]

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 the commit.

The standard client always sends deltas even for cases like yours where
the delta is not really an advantage. On receiving the delta the server
has to first reconstruct the full text and then construct a second delta
to store in the repository.

You can make commits a bit faster by using svnmucc without a working
copy, the svnmucc client always sends a delta against an empty file
which is faster to calculate than the standard client delta against the
previous file contents:

  svnmucc put some/file URL

You can make commits even faster by enabling SVNAutoversioning on the
server and using curl as your client as then the client doesn't
calculate delta at all:

  curl -XPUT @some/file URL

The curl commit will still involve calculating a delta on the server.

On my machine:

  dd:  3.3 sec 
  svn commit: 37   sec
  svnmucc commit: 26   sec
 curl commit:  9.5 sec

-- 
Philip

Re: Expected speed of commit over HTTP?

[Jacek Materna]

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 doesn't attempt to make its own determination.  I
> wasn't using .bin suffixes as it happens but I'll bet there's something in
> amongst mimetypes and suffixes somewhere that allows skipping.
>
> -ph
>
> On Thu, Jul 6, 2017 at 8:07 AM, Jacek Materna  wrote:
>
>> 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 Thu, Jul 6, 2017 at 1:54 PM, 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 position of the 512MB file and a USB3 mounted 4TB
>>> seagate hard drive being the destination.
>>>
>>> My goal is to fill the 4TB drive with commits for the simple experience
>>> of that.
>>>
>>> How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff does
>>> the 512MB temporarily manifest itself in a file system on the way to its
>>> ultimate destination?  Is 1/10th speed the expectation?  Sure, I get that
>>> 7bit/8bit shenanigans are a factor, but not that much right?
>>>
>>> - Paul
>>>
>>>
>>
>>
>> --
>>
>> Jacek Materna
>> CTO
>>
>> Assembla
>> +1 210 410 7661 <(210)%20410-7661>
>> +48 578 296 708 <+48%20578%20296%20708>
>>
>
>


-- 

Jacek Materna
CTO

Assembla
+1 210 410 7661
+48 578 296 708

Re: Expected speed of commit over HTTP?

[Paul Hammant]

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's something in
amongst mimetypes and suffixes somewhere that allows skipping.

-ph

On Thu, Jul 6, 2017 at 8:07 AM, Jacek Materna  wrote:

> 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 Thu, Jul 6, 2017 at 1:54 PM, 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 position of the 512MB file and a USB3 mounted 4TB
>> seagate hard drive being the destination.
>>
>> My goal is to fill the 4TB drive with commits for the simple experience
>> of that.
>>
>> How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff does
>> the 512MB temporarily manifest itself in a file system on the way to its
>> ultimate destination?  Is 1/10th speed the expectation?  Sure, I get that
>> 7bit/8bit shenanigans are a factor, but not that much right?
>>
>> - Paul
>>
>>
>
>
> --
>
> Jacek Materna
> CTO
>
> Assembla
> +1 210 410 7661 <(210)%20410-7661>
> +48 578 296 708 <+48%20578%20296%20708>
>

Re: Expected speed of commit over HTTP?

[Paul Hammant]

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, 2017 at 8:03 AM, Branko Čibej  wrote:

> 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 position of the 512MB file and a USB3 mounted 4TB
> > seagate hard drive being the destination.
> >
> > My goal is to fill the 4TB drive with commits for the simple
> > experience of that.
> >
> > How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff
> > does the 512MB temporarily manifest itself in a file system on the way
> > to its ultimate destination?  Is 1/10th speed the expectation?  Sure,
> > I get that 7bit/8bit shenanigans are a factor, but not that much right?
>
> 7 vs. 8bit shouldn't be an issue; data transfers are binary. If you're
> committing updates to the file, deltification could be part of the
> reason for the slowdown. Other than that ... performance measurements
> would help.
>
> -- Brane
>
>

Re: Expected speed of commit over HTTP?

[Jacek Materna]

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 Thu, Jul 6, 2017 at 1:54 PM, 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 position of the 512MB file and a USB3 mounted 4TB
> seagate hard drive being the destination.
>
> My goal is to fill the 4TB drive with commits for the simple experience of
> that.
>
> How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff does
> the 512MB temporarily manifest itself in a file system on the way to its
> ultimate destination?  Is 1/10th speed the expectation?  Sure, I get that
> 7bit/8bit shenanigans are a factor, but not that much right?
>
> - Paul
>
>


-- 

Jacek Materna
CTO

Assembla
+1 210 410 7661
+48 578 296 708

Re: Expected speed of commit over HTTP?

[Branko Čibej]

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 position of the 512MB file and a USB3 mounted 4TB
> seagate hard drive being the destination.
>
> My goal is to fill the 4TB drive with commits for the simple
> experience of that.
>
> How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff
> does the 512MB temporarily manifest itself in a file system on the way
> to its ultimate destination?  Is 1/10th speed the expectation?  Sure,
> I get that 7bit/8bit shenanigans are a factor, but not that much right?

7 vs. 8bit shouldn't be an issue; data transfers are binary. If you're
committing updates to the file, deltification could be part of the
reason for the slowdown. Other than that ... performance measurements
would help.

-- Brane

Expected speed of commit over HTTP?

[Paul Hammant]

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
seagate hard drive being the destination.

My goal is to fill the 4TB drive with commits for the simple experience of
that.

How many places in the Apache2 --> mod_dav --> mod_dav_svn handoff does the
512MB temporarily manifest itself in a file system on the way to its
ultimate destination?  Is 1/10th speed the expectation?  Sure, I get that
7bit/8bit shenanigans are a factor, but not that much right?

- Paul

Re: [ANNOUNCE] Apache Subversion 1.9.6 released

[Paul Hammant]

Great work, all round :)

Re: [ANNOUNCE] Apache Subversion 1.9.6 released

[Branko Čibej]

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 prepared the Homebrew updates in advance and created the pull
request when the release was announced. This time I don't have anything
prepared, but can do this in a day or so.

-- Brane

Re: [ANNOUNCE] Apache Subversion 1.9.6 released

[Paul Hammant]

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

[ANNOUNCE] Apache Subversion 1.9.6 released

[Daniel Shahaf]

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].  Further information is available
in the 1.9.x series release notes [2] and in a new FAQ entry [3].

[1] http://shattered.io/
[2] https://subversion.apache.org/docs/release-notes/1.9#shattered-sha1
[3] https://subversion.apache.org/faq#shattered-sha1

The SHA1 checksums are:

3375e697805fcdf6dc8c9b52f4e6626f70cabcd6 subversion-1.9.6.tar.bz2
89e1b3f9d79422c094ccb95769360d5fe7df2bb1 subversion-1.9.6.tar.gz
ba1a683297f176ef1a306dfeb894ede0236ef3b8 subversion-1.9.6.zip

SHA-512 checksums are available at:

https://www.apache.org/dist/subversion/subversion-1.9.6.tar.bz2.sha512
https://www.apache.org/dist/subversion/subversion-1.9.6.tar.gz.sha512
https://www.apache.org/dist/subversion/subversion-1.9.6.zip.sha512

PGP Signatures are available at:

http://www.apache.org/dist/subversion/subversion-1.9.6.tar.bz2.asc
http://www.apache.org/dist/subversion/subversion-1.9.6.tar.gz.asc
http://www.apache.org/dist/subversion/subversion-1.9.6.zip.asc

For this release, the following people have provided PGP signatures:

   Julian Foad [4096R/1FB064B84EECC493] with fingerprint:
6011 63CF 9D49 9FD7 18CF  582D 1FB0 64B8 4EEC C493
   Philip Martin [2048R/76D788E1ED1A599C] with fingerprint:
A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Bert Huijben [4096R/C4A6C625CCC8E1DF] with fingerprint:
3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Stefan Sperling [2048R/4F7DBAA99A59B973] with fingerprint:
8BC4 DAE0 C5A4 D65F 4044  0107 4F7D BAA9 9A59 B973
   Stefan Fuhrmann [4096R/99EC741B57921ACC] with fingerprint:
056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC
   Stefan Hett (CODE SIGNING KEY) [4096R/376A3CFD110B1C95] with fingerprint:
7B8C A7F6 451A D89C 8ADC  077B 376A 3CFD 110B 1C95
   Branko Čibej [4096R/1BCA6586A347943F] with fingerprint:
BA3C 15B1 337C F0FB 222B  D41A 1BCA 6586 A347 943F
   Daniel Shahaf [3072R/A5FEEE3AC7937444] with fingerprint:
E966 46BE 08C0 AF0A A0F9  0788 A5FE EE3A C793 7444
   Johan Corveleyn [4096R/B59CE6D6010C8AAD] with fingerprint:
8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD

Release notes for the 1.9.x release series may be found at:

http://subversion.apache.org/docs/release-notes/1.9.html

You can find the list of changes between 1.9.6 and earlier versions at:

http://svn.apache.org/repos/asf/subversion/tags/1.9.6/CHANGES

Questions, comments, and bug reports to us...@subversion.apache.org.

Thanks,
- The Subversion Team

Re: 1.8.18 release available for testing/signing

[Stefan]

On 7/6/2017 08:04, Stefan wrote:
> On 7/6/2017 04:13, Daniel Shahaf wrote:
>> Stefan wrote on Thu, 06 Jul 2017 00:14 +0200:
>>> Summary
>>> ---
>>> +0.5 to release (+1 once subversion-1.8.18.tar.gz.sha512 has been
>>> corrected - see below)
>>>
>>> Verified
>>> 
>>> subversion-1.8.18.tar.gz:
>>> Signature verified.
>>> SHA-1: 22ab7f366fb1d373247c56696b2b754c5fd06368 (matches provided
>>> SHA-1-checksum)
>>> SHA-512:
>>> 172a07ae66a53b593a3ba20d2cb3e17a926ded5b0741b7549f540aad84d42b2aad08fdc5d475f65828bcfc1d3d5526238fb850c317bb5599576f3ba9c1295245
>>> *NOTE: *subversion-1.8.18.tar.gz.sha512 is a GZIP archive containing a
>>> single file: "subversion-1.8.18.tar.gz.ahs512 which contains the SHA-512
>>> checksum matching the value above
>> The .gz.sha512 file is not compressed in the repository:
>>
>> [[[
>> % () { for 1; wget -qO- $1 | file - } 
>> https://dist.apache.org/repos/dist/dev/subversion/subversion-1.8.18.{tar.gz,tar.bz2,zip}.sha512
>>  
>> /dev/stdin: ASCII text
>> /dev/stdin: ASCII text
>> /dev/stdin: ASCII text
>> ]]]
> That's interesting... Just confirmed that indeed in the c/o of
> https://dist.apache.org/repos/dist/dev/subversion the file is not
> compressed and looks fine here too.
>> How are you downloading it?  
> Downloaded from: https://dist.apache.org/repos/dist/dev/subversion/
> using FF 54.0.1 (64-bit) on Windows 10. (direct link:
> https://dist.apache.org/repos/dist/dev/subversion/subversion-1.8.18.tar.gz.sha512
> ).
>> Might your user agent be applying
>> Content-Transfer-Encoding that the server doesn't specify?  Do you see the 
>> same
>> problem with the 1.8.18 .gz.sha1 file?
> Unlikely it's on my client side, I'd say.
> https://dist.apache.org/repos/dist/dev/subversion/subversion-1.8.18.tar.gz.sha1
> looks fine (not compressed).
>>   Do you see the same problem with
>> ?
> Nope, that file is uncompressed when I download it via FF.
>
>> (I'm trying to see whether the problem occurs on www.a.o/dist/ as well)
>>
>> Our main concern here should be to ensure that the sha512 link on the
>> download page will be usable by end users.
> +1
>> Cheers,
>>
>> Daniel
>>
>> P.S. I'm asking about ant-1.10.1 rather than subversion-1.9.6 because
>> ant uses the same EOL style as 1.8.18, whereas 1.9.6 doesn't.
>>
As per Daniel's suggestion on IRC tried:
https://dist.apache.org/repos/dist/release/ant/binaries/apache-ant-1.10.1-bin.tar.gz.sha512
- that one looks good here. Hence I agree with his conclusion that it's
some dist.a.o artifact which won't effect the sha512-files for the release.

+1 for release from me then.

Regards,
Stefan




smime.p7s
Description: S/MIME Cryptographic Signature

Re: 1.8.18 release available for testing/signing

[Stefan]

On 7/6/2017 04:13, Daniel Shahaf wrote:
> Stefan wrote on Thu, 06 Jul 2017 00:14 +0200:
>> Summary
>> ---
>> +0.5 to release (+1 once subversion-1.8.18.tar.gz.sha512 has been
>> corrected - see below)
>>
>> Verified
>> 
>> subversion-1.8.18.tar.gz:
>> Signature verified.
>> SHA-1: 22ab7f366fb1d373247c56696b2b754c5fd06368 (matches provided
>> SHA-1-checksum)
>> SHA-512:
>> 172a07ae66a53b593a3ba20d2cb3e17a926ded5b0741b7549f540aad84d42b2aad08fdc5d475f65828bcfc1d3d5526238fb850c317bb5599576f3ba9c1295245
>> *NOTE: *subversion-1.8.18.tar.gz.sha512 is a GZIP archive containing a
>> single file: "subversion-1.8.18.tar.gz.ahs512 which contains the SHA-512
>> checksum matching the value above
> The .gz.sha512 file is not compressed in the repository:
>
> [[[
> % () { for 1; wget -qO- $1 | file - } 
> https://dist.apache.org/repos/dist/dev/subversion/subversion-1.8.18.{tar.gz,tar.bz2,zip}.sha512
>  
> /dev/stdin: ASCII text
> /dev/stdin: ASCII text
> /dev/stdin: ASCII text
> ]]]
That's interesting... Just confirmed that indeed in the c/o of
https://dist.apache.org/repos/dist/dev/subversion the file is not
compressed and looks fine here too.
> How are you downloading it?  
Downloaded from: https://dist.apache.org/repos/dist/dev/subversion/
using FF 54.0.1 (64-bit) on Windows 10. (direct link:
https://dist.apache.org/repos/dist/dev/subversion/subversion-1.8.18.tar.gz.sha512
).
> Might your user agent be applying
> Content-Transfer-Encoding that the server doesn't specify?  Do you see the 
> same
> problem with the 1.8.18 .gz.sha1 file?
Unlikely it's on my client side, I'd say.
https://dist.apache.org/repos/dist/dev/subversion/subversion-1.8.18.tar.gz.sha1
looks fine (not compressed).
>   Do you see the same problem with
> ?
Nope, that file is uncompressed when I download it via FF.

> (I'm trying to see whether the problem occurs on www.a.o/dist/ as well)
>
> Our main concern here should be to ensure that the sha512 link on the
> download page will be usable by end users.
+1
>
> Cheers,
>
> Daniel
>
> P.S. I'm asking about ant-1.10.1 rather than subversion-1.9.6 because
> ant uses the same EOL style as 1.8.18, whereas 1.9.6 doesn't.

Regards,
Stefan




smime.p7s
Description: S/MIME Cryptographic Signature