Re: Changeset Signing

(resending to the list since I missed changing from the google groups email that was on the thread, my apologies to those that get this email twice) On 6/11/15 7:25 PM, Ruchir Arya wrote: > Hi Brane, i didnt get you. How can the server admin modify the content if > contents are signed? Let me give

Re: Changeset Signing

On 6/11/15 7:25 PM, Ruchir Arya wrote: > Hi Brane, i didnt get you. How can the server admin modify the content if > contents are signed? Let me give a scenario, suppose we implement Public Key > Infrastructure in SVN, where each client generates its private key and public > key and registers this

Re: Do SVN actually uses SKIP-Delta?

On 6/11/15 7:12 PM, Ruchir Arya wrote: > Hello everybody, > > Since few days i am doing my research on SVN. I always read that SVN uses > SKIP-Delta to store differences. My SVN is using FSFS file system. But when i > analysed the repository for each revision, i saw that delta in current > revisi

Re: 1.9.0-rc2 up for testing/signing

On 6/2/15 3:45 AM, Daniel Shahaf wrote: > Note that Evgeny reported a regression in svn_repos_verify_fs2() in > . No objections to > moving forward with rc2, but as that issue is a regression, we'll need > an rc3 that fixes it. I know I got tired

1.9.0-rc2 up for testing/signing

The 1.9.0-rc2 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. Thanks!

Re: Getting ready for RC2 (was: Apache Subversion 1.9.0-rc1 released)

On 5/20/15 10:47 AM, Branko Čibej wrote: > I think we can roll; I'll get started on the RM tasks tomorrow, if > on-one else wants to do this (I know Ben was going to do the 1.9 bits, > but it looks like he's out of time for that). > > In the meantime, the 1.9 release notes need a lot of work; I th

Re: Issue 4579 / svnmucc fails to process certain deletes

On 5/11/15 11:41 AM, Evgeny Kotkov wrote: > I raised an issue because I think that we care about compatibility and about > *not* breaking user scripts and tools that happen to use 'svnmucc'. Other > possible examples that work in 1.8.13, but fail in 1.9.0 RC1 include: > > svnmucc rm /A/mu rm /A

Re: 1.9.0-beta1 up for testing/signing

On 4/21/15 1:09 PM, Ben Reser wrote: > The 1.9.0-rc1 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > This being a rc1 it means that our soak pe

Re: RFC: Bump required Java version for JavaHL to 1.6

On 4/28/15 11:25 PM, Branko Čibej wrote: > Subject says it all. Two reasons: > > * Java 5 has been officially dead since 2009 > * 1.9 JavaHL uses Java6 APIs > > It's possible to cross-compile for Java5 using newer JDKs, but the > compiler only checks language features, not library usage; for

Re: 1.9.0-rc1 up for testing/signing (was 1.9.0-beta1 up for testing/signing)

On 4/21/15 1:09 PM, Ben Reser wrote: > The 1.9.0-rc1 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > This being a rc1 it means that our soak pe

1.9.0-beta1 up for testing/signing

The 1.9.0-rc1 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. This being a rc1 it means that our soak period for 1.9.0 has begun as described here: http://subversion.apache.org/

Re: Ready for 1.9.0RC1 next Friday?

On 4/20/15 6:27 AM, Julian Foad wrote: > On 17 April 2015, Ben Reser wrote: >> So once the pending backports are approved I'll roll a RC1. > > Right now there are no blockers listed in STATUS. We're ready to roll. I was waiting on the SWIG3 configure change. I didn

Re: Ready for 1.9.0RC1 next Friday?

On 4/17/15 2:42 PM, Ben Reser wrote: > If someone doesn't beat me to it I'm going to block the use of SWIG 3 for now > and adjust our release process to use the most recent SWIG 2 version for the > pre-generated sources. If we find solutions to this we can loosen this back >

Re: Ready for 1.9.0RC1 next Friday?

On 4/15/15 9:20 PM, Ben Reser wrote: > The blockers in the STATUS file are now merged. This leaves Issue #4560 and > Bert's 2 changes that can't go into 1.9.1 or later. Bert's changes look like > there's a significant possibility they will be approved soon. I was

Re: Ready for 1.9.0RC1 next Friday?

On 4/15/15 8:11 AM, Julian Foad wrote: > On 9 April 2015, Stefan Fuhrmann wrote: >> As of now, there are 2 issues scheduled for 1.9.0: >> http://subversion.tigris.org/issues/show_bug.cgi?id=4560 >> http://subversion.tigris.org/issues/show_bug.cgi?id=4565 > > #4565 is now closed. The blockers in t

Re: branching over mod_dav 2.4.6 is O(tree)

On 4/4/15 1:47 PM, Johan Corveleyn wrote: > I only know SVN, not much of httpd and certainly not much of DAV. So > I'm reading all this from behind "SVN glasses". In what cases would > SVN send lock tokens (in the form of If headers) when executing a > (server-side) copy? If by server-side copy yo

Re: branching over mod_dav 2.4.6 is O(tree)

On 4/1/15 5:28 AM, Johan Corveleyn wrote: > On Wed, Apr 1, 2015 at 1:21 PM, Philip Martin > wrote: >> Yes, I believe so. mod_dav should avoid the walk when the callback >> result for every path in the walk is known in advance. I spoke to Ben >> yesterday and he said he has an httpd patch that is

Re: [PATCH] On the 'ra-git' branch: update to libgit2 v0.22

On 3/30/15 3:13 PM, Branko Čibej wrote: > It is not. autogen.sh must not require bash. $() is not a bash'ism. It's actually in POSIX. But for whatever reason Solaris' sh does not support it so both of you are correct we can't use it.

Re: [patch] Resolve pod2man warnings

On 3/21/15 6:41 PM, James McCoy wrote: > There are a couple warnings in SVN::Core when using pod2man to generate > the man pages. Patch below fixes this. > > [[[ > Add missing POD directives to resolve pod2man warnings > > * subversion/bindings/swig/perl/native/Core.pm > (svn_log_entry_t): Add

Re: Apache Subversion 1.9.0-beta1 released

On 3/18/15 11:57 PM, Daniel Shahaf wrote: > That link isn't stable: issues disappear from it as soon as they are > merged to 1.9.x, so if we fix issue #4560 tomorrow it won't appear in > the link, even though it does affect 1.9.0-beta1. > > Next time, it would be better to explicitly list the known

Apache Subversion 1.9.0-beta1 released

1.9.0-beta1.tar.gz.asc http://www.apache.org/dist/subversion/subversion-1.9.0-beta1.zip.asc For this release, the following people have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC

Re: 1.9.0-beta1 up for testing/signing

On 3/5/15 4:09 PM, Ben Reser wrote: > The 1.9.0-beta1 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. > > Please keep in mind that this is a beta and

Re: 1.9.0-beta1 up for testing/signing

On 3/10/15 2:40 AM, Stefan Fuhrmann wrote: > basic_tests.py 38 failed over ra_serf due to faulty mod_dav; > the version check introduced in r1639507 seems incomplete r1665611 expands the versions set to XFAIL to include all the versions impacted by Apache httpd PR 55397 and PR 56480. I'll n

Re: flushing caches upon repository replacement - was: Copy and Reduce the size of SVn repos

On 3/9/15 3:12 PM, Ivan Zhakov wrote: > On 9 March 2015 at 23:31, Daniel Shahaf wrote: >> Andreas Stieger wrote on Sun, Mar 08, 2015 at 17:52:55 +0100: >>> On 08/03/15 17:45, Branko Čibej wrote: And it bears repeating: If you replace a repository, please make sure to restart Apache and/o

1.9.0-beta1 up for testing/signing

The 1.9.0-beta1 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. Please keep in mind that this is a beta and that it's going to take a significant blocker to want to avoid releas

Re: svn commit: r1663864 - /subversion/trunk/CHANGES

On 3/4/15 12:46 AM, Branko Čibej wrote: > On 04.03.2015 07:22, bre...@apache.org wrote: >> Author: breser >> Date: Wed Mar 4 06:22:07 2015 >> New Revision: 1663864 >> >> URL: http://svn.apache.org/r1663864 >> Log: >> * CHANGES: Bring up to date with 1.9.x branch. This probably needs some more >>

1.9.0-beta1 do we need it?

I'm still working on the CHANGES file for 1.9, it's taking longer than I anticipated since it's been roughly 9 months since we last did a major update (and I forgot how long that one took me). The original thinking for a beta was to get something moving while we finished up a few things we knew we

Catchup merge of trunk onto 1.9 branch?

I know that Bert has made a lot of changes he'd like to include in 1.9 on trunk. At this point since we haven't cut a release candidate I'd like to propose that we just do a catchup merge excluding anything we really don't want. I believe at this point that would just be the version bumpage. Tho

Re: 1.9.x branched

On 2/17/15 11:48 PM, Branko Čibej wrote: > On 18.02.2015 02:06, Branko Čibej wrote: >> I created the 1.9.x release branch. Trunk is now 1.10.0-dev. >> >> I also updated the buildbot configuration so that builders should be >> picking up 1.9.x changes, too. > > Oh, yes: Ben will roll the first Beta

Re: Handling assertions and malfunctions in mod_dav_svn

On 2/17/15 12:01 PM, Evgeny Kotkov wrote: > Ben Reser writes: > >> +1 except for the mod_dav_svn: prefix in the log output. httpd should be >> adding that for you with APLOG_MARK. > > I committed the patch in r1660480 and chose to keep the "mod_dav_svn:" pref

Re: Handling assertions and malfunctions in mod_dav_svn

On 2/17/15 9:44 AM, Evgeny Kotkov wrote: > I was thinking that the runtime option could be useful, because the desired > behavior might depend on the MPM being used. With non-threaded pre-forking > servers, problems with a single request wouldn't affect other requests [1]. > Threaded servers, howe

Re: svn info --detail [was: Time to branch 1.9]

On 2/16/15 3:57 AM, Branko Čibej wrote: > At first I thought I'd just lowercase the untranslated keys that 'svn > info' displays, replacing spaces with dashes. But there's a strong case > for using the same names as the --xml output; not because it's easier to > implement, but because it's at least

Re: Time to branch 1.9

On 2/15/15 6:29 PM, Branko Čibej wrote: > * 4502 Remove FSFS7 disk format changes > We've had this discussion several times. AIUI Ivan still believes we > should remove log addressing, even though all of the points he > raised have been addressed. I propose we close this issue. I've

Re: Handling assertions and malfunctions in mod_dav_svn

On 2/16/15 5:21 PM, Evgeny Kotkov wrote: > 2) Install a non-abortive mod_dav_svn malfunction handler, which would log the >malfunction details using ap_log_error() and return SVN_ERR_ASSERTION_FAIL >when CAN_RETURN = TRUE. This option is similiar to the current behavior of >a non-defau

Re: 1.7.x backport r1643074 - load with invalid mergeinfo - resolve the veto

On 2/13/15 10:07 AM, Julian Foad wrote: > Ben, you currently have a veto recorded against 1.7.x backport r1643074 - > load with invalid mergeinfo: > > > * r1643074 >Don't let invalid mergeinfo stop 'svnadmin load' from working. > Part of issue #4476 "Mergeinfo containing r0 makes svns

Intent to roll 1.8.12 & 1.7.20

Planning to roll these sometime late next week. So please wrap up any nomination/voting for things that you'd like included.

Re: [VOTE} Merge svn-auth-x509 branch to trunk?

On 1/28/15 1:50 AM, Branko Čibej wrote: > Once on trunk, it would be nice to add some tests for certs that use > SHA-256, SHA-384 and/or SHA-512 in the signature algorithm. There's already a SHA-256 certificate, but point taken.

Re: serf1.3.8. Installation for subversion on solaris 10 sparc

On 1/29/15 11:32 AM, kay wrote: > I am currently having the same issues as previous author (Mohsin). I am > trying to install serf 1.3.8 for subversion on solaris 10 sparc. I > encountered the following error which I understand is a bug on serf1.3.8 on > solaris 10. Please help. Serf mailing list

Re: [VOTE} Merge svn-auth-x509 branch to trunk?

On 1/27/15 4:55 PM, Ben Reser wrote: > I think we should get this merged to trunk. > > The original email asking to start this merge happened back in August here: > https://mail-archives.apache.org/mod_mbox/subversion-dev/201408.mbox/%3C53E1C1D7.2040005%40reser.org%3E > > Si

Re: [VOTE} Merge svn-auth-x509 branch to trunk?

On 1/28/15 6:48 PM, Evgeny Kotkov wrote: > I grepped everything between BEGIN/END certificate markers and (with a bit > of post-processing) plugged the results into the 'x509_test cert_tests[]' > data set. As a consequence, the PEM → DER conversion happened within the > test_x509_parse_cert() test

Re: [VOTE} Merge svn-auth-x509 branch to trunk?

On 1/28/15 6:55 AM, Evgeny Kotkov wrote: > Here is a couple of findings I would like to share. > > I took the certificates from a regression suite in [1] and fed them to the new > X509 parser, svn_x509_parse_cert(). The parser currently fails to parse 20 of > the test certificates, mostly with an

[VOTE} Merge svn-auth-x509 branch to trunk?

I think we should get this merged to trunk. The original email asking to start this merge happened back in August here: https://mail-archives.apache.org/mod_mbox/subversion-dev/201408.mbox/%3C53E1C1D7.2040005%40reser.org%3E Since that email the checksum formatting code was removed and there have

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

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: Logging of subrequest authorization checks in mod_dav_svn/mod_authz_svn

On 1/16/15 11:52 AM, C. Michael Pilato wrote: > As for log levels, is there any reason to log the implicit read attempts > at a level higher than "debug"? I have no opinion about the log level > for the explicit ones. I can see some people possibly wanting this information for auditing purposes.

Re: svn commit: r1631598 - in /subversion/trunk/subversion: libsvn_fs_fs/verify.c tests/libsvn_fs_fs/fs-fs-fuzzy-test.c

On 1/13/15 11:44 AM, Ben Reser wrote: > On 1/13/15 11:34 AM, Ben Reser wrote: >> On 1/13/15 11:13 AM, Branko Čibej wrote: >>> Since it is a test, what's wrong with just casting the first vararg to >>> (apr_uint64_t) instead, since we "know" (i.e., h

Re: svn commit: r1631598 - in /subversion/trunk/subversion: libsvn_fs_fs/verify.c tests/libsvn_fs_fs/fs-fs-fuzzy-test.c

On 1/13/15 11:34 AM, Ben Reser wrote: > On 1/13/15 11:13 AM, Branko Čibej wrote: >> Since it is a test, what's wrong with just casting the first vararg to >> (apr_uint64_t) instead, since we "know" (i.e., hope) that off_t won't >> overflow 64 bits ... &

Re: svn commit: r1631598 - in /subversion/trunk/subversion: libsvn_fs_fs/verify.c tests/libsvn_fs_fs/fs-fs-fuzzy-test.c

On 1/13/15 11:13 AM, Branko Čibej wrote: > Since it is a test, what's wrong with just casting the first vararg to > (apr_uint64_t) instead, since we "know" (i.e., hope) that off_t won't > overflow 64 bits ... If you cast it to apr_uint64_t it can read into memory it shouldn't be (i.e. the test may

Re: svn commit: r1631598 - in /subversion/trunk/subversion: libsvn_fs_fs/verify.c tests/libsvn_fs_fs/fs-fs-fuzzy-test.c

On 10/13/14 3:54 PM, stef...@apache.org wrote: > Author: stefan2 > Date: Mon Oct 13 22:54:13 2014 > New Revision: 1631598 > > URL: http://svn.apache.org/r1631598 > Log: > Add FSFS index checksum verification code to 'svnadmin verify'. > > We don't verify the index data against the checksums on ev

Apache Subversion 1.8.11 released

vided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F

Apache Subversion 1.7.19 released

vided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Ivan Zhakov [4096R/F6AD8147] with fingerprint: 4829 8F0F E47F

Re: 1.7.19 and 1.8.11 [was: svn commit: r1645547 - in /subversion/branches: 1.7.x/STATUS 1.8.x/STATUS]

On 12/14/14 6:11 PM, Branko Čibej wrote: > As you've all seen, I voted against releasing 1.7.19 and 1.8.11, because > the DAV tests don't work with HTTPd 2.4+, which is the system default on > the latest version of OSX. I'd be surprised if OSX is the exception; it > seems to depend not just on the

1.8.11 up for testing/signing

The 1.8.11 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. I plan to try and release on December 15th so please try and get your votes/signatures in place by December 13th. Thi

1.7.19 up for testing/signing

The 1.7.19 release artifacts are now available for testing/signing. Please get the tarballs from https://dist.apache.org/repos/dist/dev/subversion and add your signatures there. I plan to try and release on December 15th so please try and get your votes/signatures in place by December 13th. Thi

Re: svn commit: r1643189 - in /subversion/branches/1.7.x: ./ subversion/ subversion/include/svn_repos.h subversion/libsvn_repos/load-fs-vtable.c subversion/tests/libsvn_repos/repos-test.c subversion/t

With careful effort of stefan2 and myself we've reverted this. It was mistakenly merged onto the 1.7.x branch not the 1.7.x-r1643074 branch. Not only that but the merge it says it's doing is not what it did, it was actually a merge of r1643119 on 1.8.x-r1643074. I found this only because the mer

Re: 1.7.19 and 1.8.11 next week

On 11/27/14 12:42 AM, Ben Reser wrote: > I plan to roll these releases sometime next week. Please vote for issues. > Preferably I'd like to get them done on Monday but I know the rest of this > week > is a holiday for some people (myself included) so if we have important thing

Re: svn commit: r1637826 - /subversion/trunk/autogen.sh

On 11/10/14 4:28 AM, br...@apache.org wrote: > ltpath="`dirname $libtoolize`" > -ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/libtool.m4} > +ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`}/libtool.m4 > > if [ ! -f $ltfile ]; then > echo "$ltfile not found (try setting t

1.7.19 and 1.8.11 next week

I plan to roll these releases sometime next week. Please vote for issues. Preferably I'd like to get them done on Monday but I know the rest of this week is a holiday for some people (myself included) so if we have important things needing votes it may get delayed later into the week.

Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'

On 11/6/14 8:40 PM, Nico Kadel-Garcia wrote: > Isn't clang installed with MacPorts? Or is that just more recent > versions of clang? Barry said in his original posting he was using clang from XCode 6.1 command line tools package, which is Apple's official distribution of a compiler toolchain for O

Re: Time to branch 1.9

On 11/6/14 8:44 AM, Greg Stein wrote: > That is no "decision" because it didn't occur here on the list. It certainly was discussed on this list: http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/%3C51B9C8AB.9090203%40collab.net%3E A number of us have been operating under the ass

Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'

On 11/6/14 5:10 AM, Nico Kadel-Garcia wrote: > Out of curiosity, do the same issues occur with gcc on a modern box? > Ther'e's a lot to like about MacPorts, but I don't think it's the > primary build and testing platform for Subversion. Yes gcc is going to have the same issues because the declarat

Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'

On 11/5/14 12:37 PM, Mark Phippard wrote: > FWIW, Barry is the pysvn developer. Ahh well then never mind my pointer to his project.

Re: pysvn does not build against 1.9-alpha2 because of incomplete type 'const svn_sort__item_t'

On 11/5/14 10:49 AM, Barry Scott wrote: > I have been building pysvn against the latest svn kits. 1.7.18, 1.8.10 and > 1.9.0-alpha2 > using the Mac OS X Xcode 6.1 command line tools, clang is the compiler not > gcc. > > Compiling and testing pysvn against 1.7.18 and 1.8.10 works with no errors.

Re: Our website is broken

On 11/3/14 11:09 AM, Mark Phippard wrote: > Server-side includes not working I would guess? Should be fixed now.

Re: Our website is broken

On 11/3/14 11:52 AM, Andreas Stieger wrote: > Depending on which back-end is hit, the content below is incorrectly > delivered. Corr: now always. I have first seen this late last week. > >> >> >> >> >> Of the 3 servers that are setup for subversion.apache.org [[[ $ dig +short subversion.ap

Re: Our website is broken

On 11/3/14 11:09 AM, Mark Phippard wrote: > Assume it is just not for me, but our menu does not appear. > > http://subversion.apache.org > > Server-side includes not working I would guess? Working for me.

Re: svn commit: r1634906 - in /subversion/branches/svn-auth-x509/subversion: include/svn_x509.h libsvn_subr/x509.h libsvn_subr/x509info.c libsvn_subr/x509parse.c svn/auth-cmd.c tests/libsvn_subr/x509-

On 10/28/14 9:26 AM, Branko Čibej wrote: > Indentation is wrong. Whoops, somehow my code style setting got disabled when I wrote this and didn't notice it. Fixed in r1635359. > And I suggest using svn_iter_apr_array here. > ... and svn_iter_apr_hash here. Unless it's a big deal to you I'm not i

Re: Some x509 branch review points

On 10/15/14 3:15 AM, Philip Martin wrote: > 1) > > In x509parse.c:x509_get_version: > > err = asn1_get_tag(p, end, &len, > ASN1_CONTEXT_SPECIFIC | ASN1_CONSTRUCTED | 0); > > Why the "| 0"? It doesn't do anything. The 0 is there to say that the context specific value is 0

Re: svn:mime-type arbitrary parameters

On 10/26/14 11:35 AM, Branko Čibej wrote: > The fact that the svn:mime-type property is usable in any way for > serving content from the repository is more or less an accident; it's > definitely not a design goal. What you propose would have zero benefit > for Subversion as a version control system

Re: svn:mime-type arbitrary parameters

On 10/26/14 11:35 AM, Branko Čibej wrote: > The fact that the svn:mime-type property is usable in any way for > serving content from the repository is more or less an accident; it's > definitely not a design goal. What you propose would have zero benefit > for Subversion as a version control system

Re: [PATCH] Introduce per-instance filesystem UUIDs

On 8/20/14 9:13 AM, Ben Reser wrote: > I think part of the problem here has been we (as in WANdisco folks) have > discussed the idea of an instance ID for repositories in the past to solve the > range of replacing the repository without clearing the cache issues. But this > change is

Re: r1619122 (stsp) broke 'make swig-py'

On 8/21/14 9:39 AM, Ben Reser wrote: > I have the "correct" fix but in so much as it makes things compile. But I > don't know that it makes the svn_wc_conflict_description2_t setters do > anything > useful. Writing a test now, so I should have it fixed shortly. I

Re: r1619122 (stsp) broke 'make swig-py'

On 8/21/14 1:29 AM, Alexey Neyman wrote: > The new fields added in svn_wc.h cause the following errors: > > subversion/bindings/swig/python/svn_wc.c: In function > ‘_wrap_svn_wc_conflict_description2_t_prop_value_base_set’: > subversion/bindings/swig/python/svn_wc.c:8798: error: ‘_global_pool’ >

Re: [PATCH] Introduce per-instance filesystem UUIDs

On 8/19/14 12:07 AM, Branko Čibej wrote: > I think it's not that simple. > > Consider the case where an administrator decides to not use 'svnadmin hotcopy' > to back up a repository, but instead creates a (LVM) snapshot of the volume > and > uses 'tar' (or 'cp -a') to create the backup. > > When

Re: Python bindings: core.Stream missing close method?

On 8/19/14 11:08 PM, Alexey Neyman wrote: > Hi, > > It looks like the core.Stream class does not close the underlying streams. It > does save reference to a svn_stream_t wrapper in self._stream, but does not > call svn_stream_close() on its own deletion, nor does the auto-generated > svn_stream

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/8/14 1:14 AM, Ben Reser wrote: > On 8/5/14 10:49 PM, Ben Reser wrote: >> I believe the svn-auth-x509 branch is ready to be merged to trunk. There is >> no >> BRANCH-README so I'll briefly explain the purpose of the branch. > > Cleaned up several warnings

Re: svn commit: r1618860 - in /subversion/trunk: build.conf subversion/svn-bench/ tools/client-side/svn-bench/

On 8/19/14 2:40 PM, C. Michael Pilato wrote: > Define "published". I don't see svn-bench installed on my Subversion > 1.8 system. We renamed "mucc" to "svnmucc" when we promoted it to > first-class binary status after it had already been "published" in the > 'tools' area in *several* minor releas

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/12/14 4:39 PM, Branko Čibej wrote: > This thing against flags and booleans that change API behaviour does have a > very good argument going for it: it makes the code less obvious for the sake > of > saving a few function names. > > Consider the standard example, which (these days) would be a

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/12/14 3:55 PM, Bert Huijben wrote: > Since WC-NG we tried not to introduce new functions with flag arguments as in > general functions like that are hard to maintain, while it is easy to rev > functions to add another separate argument. (Another less preferred option is > using a struct with s

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/12/14 12:56 PM, Ivan Zhakov wrote: > My concerns are the following: > 1. Avoid unrelated branch changes > 2. Have some function for converting checksum to canonical form: >a) one option is just leave svn_checksum_to_cstring_display() and > add svn_checksum_to_cstring_display_ex() >b) a

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/11/14 1:59 AM, Ivan Zhakov wrote: > My primary concerns was that with svn_checksum_to_cstring_display2() > we have to care at every place to use proper flags to get some > canonical representation for protocol/storage. How about svn_checksum_to_cstring_canonical() which is just this macro: #d

Apache Subversion 1.7.18 released

eople have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint:

Apache Subversion 1.8.10 released

eople have provided PGP signatures: Ben Reser [4096R/16A0DE01] with fingerprint: 19BB CAEF 7B19 B280 A0E2 175E 62D4 8FAD 16A0 DE01 Bert Huijben [4096R/CCC8E1DF] with fingerprint: 3D1D C66D 6D2E 0B90 3952 8138 C4A6 C625 CCC8 E1DF Branko Čibej [2048R/C8628501] with fingerprint:

Re: Regression in bindings? 1.7/1.8 vs 1.6

Side note this is in the pre-commit.tmpl that we create when you create a repository: [[[ # *** NOTE: THE HOOK PROGRAM MUST NOT MODIFY THE TXN, EXCEPT *** # *** FOR REVISION PROPERTIES (like svn:log or svn:author). *** ]]] On 8/10/14 7:36 PM, Alexey Neyman wrote: > So, the unversioned pr

Re: Regression in bindings? 1.7/1.8 vs 1.6

On 8/10/14 5:19 PM, Alexey Neyman wrote: > - First, if the fs.change_node_prop was not intended for use in scripts, why > is > it exposed in bindings at all? Bindings are not intended just for writing hook scripts. Rather the bindings are intended to wrap the entirety of our C API (though someti

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/10/14 7:35 AM, Ben Reser wrote: > There shouldn't be any such certificate that's valid (at least that's using > the > Internet profile for X.509). There are two places that the signature > algorithm > are specified in the certificate. First in the Certifica

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/10/14 5:03 AM, Ivan Zhakov wrote: > I agree svn_checksum_to_cstring_display() is wrong name and the proper > solution to make separated (probably) optimized function for > converting checksum to canonical string representation. But this is > definitely out of scope of this branch. I've gone ah

Re: 1.7.18 up for testing/signing

On 8/9/14 7:10 AM, Ben Reser wrote: > Voting stands now at 2 for Unix and 2 for Windows. Need one more vote from > both camps. Reminder, in order to release on the 11th we need votes in by the > 10th. So I'd really appreciate if we can get these votes in the next day. With Brank

Re: 1.7.18 up for testing/signing

On 8/7/14 8:07 AM, Ben Reser wrote: > On 8/1/14 6:32 PM, Ben Reser wrote: >> The 1.7.18 release artifacts are now available for testing/signing. >> Please get the tarballs from >> https://dist.apache.org/repos/dist/dev/subversion >> and add your signatures there. I

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/7/14 5:58 PM, Branko Čibej wrote: > I've seen platforms where size_t was smaller than ptrdiff_t; but usually > they're the same size. The rules of type promotion in C state that an a value > of a signed type can be promoted to a value of the same-sized unsigned type > without truncation, where

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/5/14 10:49 PM, Ben Reser wrote: > I believe the svn-auth-x509 branch is ready to be merged to trunk. There is > no > BRANCH-README so I'll briefly explain the purpose of the branch. Cleaned up several warnings based on feedback from Ivan and things I found while looking

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/7/14 4:34 PM, Ben Reser wrote: > I expected that change would just shift the warnings around but it removes the > warnings entirely. I'm still not sure it's right. We're setting a ptrdiff_t > with the value from an apr_size_t. Shouldn't that result in a pos

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/7/14 12:16 PM, Branko Čibej wrote: > On 07.08.2014 19:03, Ben Reser wrote: >> This appears to be because pointers are unsigned and apr_size_t is signed. > > You mean the other way around, surely. Yes, thinko. >> Guess we can just cast the pointer arithmetic to apr_si

Re: 1.8.10 up for testing/signing

On 8/7/14 8:05 AM, Paul Burba wrote: > I'll have windows test results incoming at some point today. Same for 1.7.18. Thanks Paul, it's greatly appreciated.

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/7/14 4:10 AM, Ivan Zhakov wrote: > Several comments on branch code itself: > 1. Probably it makes sense to do not deprecate > svn_checksum_to_cstring_display() or have local x509 implementation > for fingerprint formatting because we use > svn_checksum_to_cstring_display() as canonical represe

Re: [VOTE] Merge svn-auth-x509 branch to trunk?

On 8/6/14 2:09 PM, Stefan Fuhrmann wrote: > What would a worst-case failure scenario look like? Could a faulty > parser result in the auth store reporting keys that the user does not > want to trust (e.g. by stitching together random portions of the file)? I'll go ahead and answer the question I t

Re: 1.7.18 up for testing/signing

On 8/1/14 6:32 PM, Ben Reser wrote: > The 1.7.18 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. I plan to try and release on August 11th so > please t

Re: 1.8.10 up for testing/signing

On 8/1/14 6:33 PM, Ben Reser wrote: > The 1.8.10 release artifacts are now available for testing/signing. > Please get the tarballs from > https://dist.apache.org/repos/dist/dev/subversion > and add your signatures there. I plan to try and release on August 11th so > please t

[VOTE] Merge svn-auth-x509 branch to trunk?

I believe the svn-auth-x509 branch is ready to be merged to trunk. There is no BRANCH-README so I'll briefly explain the purpose of the branch. Currently on trunk we have the `svn auth` command that can list out the contents of the auth store. The auth store can include SSL server certificates.

Re: 1.7.18 up for testing/signing

On 8/4/14 3:15 AM, Stefan Fuhrmann wrote: > On Ubuntu 14.04.1, the ruby bindings won't build because > configure insists in 1.8.x while the system has 1.9.x. > > If that's a known / acceptable limitation, I'll +1 the release. Ruby 1.9+ support wasn't added until 1.8.x so yes that's an expected li

  1   2   3   4   5   6   7   8   9   >