Re: Bug in "svnrdump" ?

2017-03-01 Thread Doug Robinson
Julian: No need to drive it further at this time. Thank you. Doug On Thu, Feb 23, 2017 at 9:15 AM, Julian Foad wrote: > Doug Robinson wrote: > >> https://issues.apache.org/jira/browse/SVN-4672 >> > > Thanks, Doug, that's great. Let me know if you need me to drive it >

Re: Files with identical SHA1 breaks the repo

2017-03-01 Thread Garance A Drosehn
On 1 Mar 2017, at 7:18, Daniel Shahaf wrote: > Stefan Sperling wrote on Wed, Mar 01, 2017 at 11:01:40 +0100: >> On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote: >>> I really like this idea. >>> >>> And we could take a copy of APR's sha1 code, and rejigger >>> it to perform *both*

Re: Fast alternative hash

2017-03-01 Thread Branko Čibej
On 01.03.2017 13:52, Stefan Fuhrmann wrote: > On 01.03.2017 05:17, Greg Stein wrote: >> I really like this idea. >> >> And we could take a copy of APR's sha1 code, and rejigger it to >> perform *both* hashes during the same scan of the raw bytes. I would >> expect the time taken to extend by (say)

Fast alternative hash (was: Files with identical SHA1 breaks the repo)

2017-03-01 Thread Stefan Fuhrmann
On 01.03.2017 05:17, Greg Stein wrote: I really like this idea. And we could take a copy of APR's sha1 code, and rejigger it to perform *both* hashes during the same scan of the raw bytes. I would expect the time taken to extend by (say) 1.1X rather than a full 2X. The inner loop might cost

Re: Files with identical SHA1 breaks the repo

2017-03-01 Thread Daniel Shahaf
Stefan Sperling wrote on Wed, Mar 01, 2017 at 11:01:40 +0100: > On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote: > > I really like this idea. > > > > And we could take a copy of APR's sha1 code, and rejigger it to perform > > *both* hashes during the same scan of the raw bytes. I would

Re: Files with identical SHA1 breaks the repo

2017-03-01 Thread Stefan Sperling
On Tue, Feb 28, 2017 at 10:17:34PM -0600, Greg Stein wrote: > I really like this idea. > > And we could take a copy of APR's sha1 code, and rejigger it to perform > *both* hashes during the same scan of the raw bytes. I would expect the > time taken to extend by (say) 1.1X rather than a full 2X.