Re: Stack overflow in checksum.c

On Tue, Jan 27, 2015 at 5:07 AM, Hyrum K Wright wrote: > There's a stack overflow bug in subversion/libsubr/checksum.c. > Well, a segfault. > > The functions svn_checksum__from_digest_fnv1a_32x4() and > svn_checksum__from_digest_fnv1a_32() both look something like this: > > svn_checksum_t * > s

[l10n] Translation status report for trunk r1654975

Translation status report for trunk@r1654975 lang trans untrans fuzzy obs -- de2873 3 10 492 +~o es2265 611 830 528 ++U~~~ fr2569 307

Stack overflow in checksum.c

There's a stack overflow bug in subversion/libsubr/checksum.c. The functions svn_checksum__from_digest_fnv1a_32x4() and svn_checksum__from_digest_fnv1a_32() both look something like this: svn_checksum_t * svn_checksum__from_digest_fnv1a_32x4(const unsigned char *digest, apr_pool_t *result

Issue 4554 - Heads up

This issue is about a gap between FSFS spec and implementation. Generalized rep sharing in 1.8 made that gap visible but it has always been there. No data is being lost and checkout etc. should work. However, dump files generated from the affected repos will not load. There are 2 places in mod_d

Re: svnadmin dump/filter/load problems with bad rev references

Hi Julian, Thanks for keeping me in the loop. The workaround with +1/-1 when getting the mapping rev seems to work for now. /Patrik On Mon, Jan 26, 2015 at 10:09 AM, Julian Foad wrote: > Hi Patrik. > > Just to let you know, I have not started on this issue yet, but have still > got this flagg

Re: svnadmin dump/filter/load problems with bad rev references

Hi Patrik. Just to let you know, I have not started on this issue yet, but have still got this flagged for attention and have been sorting out other dump/load issues which hopefully will make this one easier to address. If necessary (if I don't get to it soon) I'll file an issue to track it so

Re: CentOS buildbot

Ben Reser wrote: > On 1/26/15 11:24 AM, Julian Foad wrote: >> I think it's useful to have builders at both ends of the spectrum: > minimal/oldest, and also bleeding-edge/all-fancy-options. >> >> Any reason we shouldn't request two VMs and maintain both? I can't > see it being an unacceptable

Re: CentOS buildbot

On 1/26/15 11:24 AM, Julian Foad wrote: > I think it's useful to have builders at both ends of the spectrum: > minimal/oldest, and also bleeding-edge/all-fancy-options. > > Any reason we shouldn't request two VMs and maintain both? I can't see it > being an unacceptable computing load nor admini

Re: CentOS buildbot

  -- Join WANdisco's free daily demo sessions on Scaling Subversion for the Enterprise - Original Message - > From: Ben Reser > To: Subversion Development > Cc: > Sent: Monday, 26 January 2015, 18:59 > Subject: CentOS buildbot > > Seems

CentOS buildbot

Seems that the machine that was running our CentOS buildbot has disappeared. We can get a new one setup (probably a VM, not sure if the old one was physical hardware or a VM). But the question is now what do we want. The CentOS buildbot was running a rather old version of CentOS, we actually had

Re: Testing equality between svnrdump and svnadmin dump

Branko Čibej wrote: > On 26.01.2015 15:50, Julian Foad wrote: >>  Excellent. Is anyone able to lend a hand with one of these two of the tasks >> I listed: >> >>    - Bypass authz when dumping with svnrdump, otherwise a partial dump is >>      obtained for tests using authz, making those tests fai

Re: Testing equality between svnrdump and svnadmin dump

On 26.01.2015 15:50, Julian Foad wrote: > Branko Čibej wrote: >> On 26.01.2015 14:13, Julian Foad wrote: >>> I attach the latest version of my dump/load cross-checking patch. >>> >>> Do we want to commit this? I think we should. It has been very useful in >> uncovering dump/load bugs and incon

Re: Testing equality between svnrdump and svnadmin dump

On Mon, Jan 26, 2015 at 7:57 AM, Julian Foad wrote: > Hi Bert! Thanks for airing your concerns. > > Bert Huijben wrote: > > I see added value in these tests, but can we please make this behavior > optional > > before enabling for everybody all the time? > > Certainly! That's one of the three TODO

Re: Testing equality between svnrdump and svnadmin dump

Hi Bert! Thanks for airing your concerns. Bert Huijben wrote: > I see added value in these tests, but can we please make this behavior > optional > before enabling for everybody all the time? Certainly! That's one of the three TODO tasks I listed. > I don't see why every test in the testsuite

Re: Testing equality between svnrdump and svnadmin dump

Branko Čibej wrote: > On 26.01.2015 14:13, Julian Foad wrote: >>  I attach the latest version of my dump/load cross-checking patch. >> >>  Do we want to commit this? I think we should. It has been very useful in > uncovering dump/load bugs and inconsistencies. > > Absolutely +1, more tests can't

RE: Testing equality between svnrdump and svnadmin dump

> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: maandag 26 januari 2015 15:17 > To: dev@subversion.apache.org > Subject: Re: Testing equality between svnrdump and svnadmin dump > > On 26.01.2015 14:13, Julian Foad wrote: > > I attach the latest version of my

Re: Testing equality between svnrdump and svnadmin dump

On 26.01.2015 14:13, Julian Foad wrote: > I attach the latest version of my dump/load cross-checking patch. > > Do we want to commit this? I think we should. It has been very useful in > uncovering dump/load bugs and inconsistencies. Absolutely +1, more tests can't hurt. -- Brane

Re: svn commit: r1653988 - in /subversion/trunk/subversion: svnrdump/load_editor.c tests/cmdline/svnrdump_tests.py

I (Julian Foad) wrote: > I (Julian Foad) wrote: >> Bert Huijben wrote: URL: http://svn.apache.org/r1653988 Log: Fix issue #4551 "svnrdump load commits wrong properties, or fails, on a non-deltas dumpfile", [...] >>> >>> I also see new test failures on the two new tests for ra_s

Re: Testing equality between svnrdump and svnadmin dump

I attach the latest version of my dump/load cross-checking patch. Do we want to commit this? I think we should. It has been very useful in uncovering dump/load bugs and inconsistencies. It needs a bit more work first, as noted in the log message: ### TODO:   - Put back the dumpfile parser's abi

Re: [PATCH] Fix build errors in bindings with SWIG 3.0.4

Andreas Stieger writes: > Index: subversion/bindings/swig/include/proxy.swg > === > --- subversion/bindings/swig/include/proxy.swg(revision 1654697) > +++ subversion/bindings/swig/include/proxy.swg(working copy) > @@