Re: svnauth ssl cert support -- please check windows build

On Wed, Jul 10, 2013 at 5:33 AM, Stefan Sperling wrote: > Here's a rough patch that makes svnauth show SSL certs as a list > of fields, rather than a long base64 string. > > I'm adding a dependency on OpenSSL for certificate parsing. > I hope this is fine. If OpenSSL is not available svnauth falls

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej wrote: > On 09.07.2013 05:53, Greg Stein wrote: >... >> For *this* project, that is absolutely the case. We have never said >> "let's work against any server anybody decides to implement." We write >> to our client, and our server, and third parties ad

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 9, 2013 at 8:04 PM, Joseph Schaefer wrote: > You've made some interesting and educational points on what veto rights are > all about Greg, and I appreciate that quite a bit. I do think that it'd be > worthwhile to document this on the foundation website because it's a common > poin

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

You've made some interesting and educational points on what veto rights are all about Greg, and I appreciate that quite a bit. I do think that it'd be worthwhile to document this on the foundation website because it's a common point of frustration for many projects, from well-established ones t

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 9, 2013 at 6:48 PM, Daniel Shahaf wrote: > A veto not accompanied by a technical reason is invalid. I am seeking > consensus on the dev@ list that no technical reason was given. No one > is going to strip anyone's bits. Daniel is right on this one: "To prevent vetos from being used

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 9, 2013 at 9:48 PM, Daniel Shahaf wrote: >... > A veto not accompanied by a technical reason is invalid. I am seeking > consensus on the dev@ list that no technical reason was given. No one > is going to strip anyone's bits. It's a slippery slope that you want to avoid. Very very mu

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On 09.07.2013 05:53, Greg Stein wrote: > On Mon, Jul 8, 2013 at 9:52 PM, Ben Reser > wrote: > >... > > Greg's argument here mostly depends on the idea that Subversion is > built to work against mod_dav_svn and any proxy or implementation that > doesn't implement

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On 10.07.2013 02:16, Daniel Shahaf wrote: > On Tue, Jul 09, 2013 at 11:51:09PM +0200, Bert Huijben wrote: >> (I don't know about our JavaHL users, but I know more than a few SharpSvn >> users that have checks for specific error codes in their products) > Do the codes the check for have svn_error_c

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 09, 2013 at 09:13:07PM -0400, Greg Stein wrote: > On Tue, Jul 9, 2013 at 9:10 PM, Greg Stein wrote: > > On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf wrote: > >>... > >> So, I submit that your veto lacks a technical basis, and is therefore > >> invalid, > >> and has no standing. > >

svnauth ssl cert support -- please check windows build

Here's a rough patch that makes svnauth show SSL certs as a list of fields, rather than a long base64 string. I'm adding a dependency on OpenSSL for certificate parsing. I hope this is fine. If OpenSSL is not available svnauth falls back to printing the base64 encoded form of the certificate. Sin

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 9, 2013 at 9:10 PM, Greg Stein wrote: > On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf wrote: >>... >> So, I submit that your veto lacks a technical basis, and is therefore >> invalid, >> and has no standing. > > You do not get to make that decision. Certainly not unilaterally. If > y

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf wrote: >... > So, I submit that your veto lacks a technical basis, and is therefore invalid, > and has no standing. You do not get to make that decision. Certainly not unilaterally. If you feel it is invalid, then your course of action is to bring it

Re: Semantics of svn_error_t->apr_err

On Tue, Jul 9, 2013 at 4:40 PM, Daniel Shahaf wrote: > Bert Huijben wrote on Tue, Jul 09, 2013 at 22:32:00 +0200: >... >> There is no rule that apr_err must be set to something that is defined by >> APR or Subversion. Correct. > I've nothing new to say. I think every svn_error_t we return from

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Wed, Jul 10, 2013 at 02:52:21AM +0400, Ivan Zhakov wrote: > On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben wrote: > >> -Original Message- > >> From: Branko ??ibej [mailto:br...@wandisco.com] > >> Sent: dinsdag 9 juli 2013 23:12 > >> To: dev@subversion.apache.org > >> Subject: Re: svn com

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 09, 2013 at 11:51:09PM +0200, Bert Huijben wrote: > (I don't know about our JavaHL users, but I know more than a few SharpSvn > users that have checks for specific error codes in their products) Do the codes the check for have svn_error_codes.h names? If yes, they are not relevant ex

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Tue, Jul 09, 2013 at 11:51:09PM +0200, Bert Huijben wrote: > So: What are we talking about here? > > An 'svn'-only user wants to see different error codes? > > (Perhaps he added patch over patch to make the numbers more visible in > MAINTAINER mode?) First and foremost, can you please quit m

Re: build-svn-deps-win.pl and debug builds

On Tue, Jul 9, 2013 at 1:44 PM, Johan Corveleyn wrote: > It would be interesting if build-svn-deps-win.pl could also build > debug builds of the dependencies (so I can use them to make a debug > build of svn). Agreed this was on my todo list. Just haven't gotten to it. > I suppose this is basic

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben wrote: >> -Original Message- >> From: Branko Čibej [mailto:br...@wandisco.com] >> Sent: dinsdag 9 juli 2013 23:12 >> To: dev@subversion.apache.org >> Subject: Re: svn commit: r1501371 - >> /subversion/trunk/subversion/libsvn_ra_serf/util_error.

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On Tue, Jul 9, 2013 at 7:33 PM, Ben Reser wrote: > On Tue, Jul 9, 2013 at 1:25 AM, Stefan Sperling wrote: >> On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote: >>> The option doesn't seem like a big barrier when you're applying it to >>> a handful of machines for yourself. Scale that eff

RE: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: dinsdag 9 juli 2013 23:12 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1501371 - > /subversion/trunk/subversion/libsvn_ra_serf/util_error.c > > On 09.07.2013 23:00, Bert Huijben wrote: > > I woul

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On 09.07.2013 23:00, Bert Huijben wrote: > I would welcome a patch to svn_strerror that improves the default > error for serf specific error codes, That would effectively make our make implementation details of libsvn_ra_serf part of the public API. That's a non-strarter IMO. > or a patch that tr

RE: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

> -Original Message- > From: Branko Čibej [mailto:br...@wandisco.com] > Sent: dinsdag 9 juli 2013 22:48 > To: dev@subversion.apache.org > Subject: Re: svn commit: r1501371 - > /subversion/trunk/subversion/libsvn_ra_serf/util_error.c > > On 09.07.2013 22:32, Bert Huijben wrote: > > > >> -

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

On 09.07.2013 22:32, Bert Huijben wrote: > >> -Original Message- >> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] >> Sent: dinsdag 9 juli 2013 22:16 >> To: Bert Huijben >> Cc: dev@subversion.apache.org; comm...@subversion.apache.org >> Subject: Re: svn commit: r1501371 - >> /subversi

build-svn-deps-win.pl and debug builds

It would be interesting if build-svn-deps-win.pl could also build debug builds of the dependencies (so I can use them to make a debug build of svn). I suppose this is basically using "Debug" throughout the file where it currently says "Release", and installd instead of installr for httpd etc. [1]

Semantics of svn_error_t->apr_err

Bert Huijben wrote on Tue, Jul 09, 2013 at 22:32:00 +0200: > > -Original Message- > > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > Bert Huijben wrote on Tue, Jul 09, 2013 at 20:11:57 +0200: > > > How is this going to help? > > > > I already told you how: it is going to help bec

RE: svn commit: r1501360 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 9 juli 2013 22:06 > To: dev@subversion.apache.org > Cc: comm...@subversion.apache.org > Subject: Re: svn commit: r1501360 - > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > rhuij...@apache.org

RE: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 9 juli 2013 22:16 > To: Bert Huijben > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > Subject: Re: svn commit: r1501371 - > /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

Re: Adding ldap group support to subversion

On Tue, Jul 09, 2013 at 12:46:36AM +0800, 刘新星 wrote: > What I am doing is to add ldap group support for subversion. Which means we > don't need any predefined groups in authz file. We get groups from ldap > server directly. Hello, thank you very much for this patch! I have some questions and su

Re: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

Bert Huijben wrote on Tue, Jul 09, 2013 at 20:11:57 +0200: > Same as for all previous patches in line: > "All previous patches"? There was one previous patch along these lines. > How is this going to help? I already told you how: it is going to help because API users can't do anything with t

Re: svn commit: r1501360 - /subversion/trunk/subversion/libsvn_wc/wc_db.c

rhuij...@apache.org wrote on Tue, Jul 09, 2013 at 16:09:33 -: > @@ -13532,6 +13533,9 @@ wclock_obtain_cb(svn_wc__db_wcroot_t *wc > + if (enforce_empty_wq) > +svn_wc__db_verify_no_work(wcroot->sdb); Missing SVN_ERR wrapper. > @@ -13679,9 +13683,6 @@ svn_wc__db_wclock_obtain(svn_wc__db_t *

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

Bert Huijben wrote on Tue, Jul 09, 2013 at 20:02:48 +0200: > > > > -Original Message- > > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > > Sent: dinsdag 9 juli 2013 18:39 > > To: dev@subversion.apache.org > > Cc: comm...@subversion.apache.org > > Subject: Re: svn commit: r150104

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

On Jul 9, 2013 12:52 PM, "Ben Reser" wrote: > > On Tue, Jul 9, 2013 at 12:55 AM, Ben Reser wrote: > > Have we considered just turning off chunked requests entirely until > > Serf has a fix to automatically detect and handle servers that don't > > support chunked requests? I've seen a lot of disc

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On 07/09/2013 10:33 AM, Ben Reser wrote: So we had a conversation on IRC this morning about solutions. This is what several of us seemed to agree was a reasonable compromise: Have a tri-state option called http-chunked-requests. It would have three states: auto = Run the extra OPTIONS request

Re: 1.8.1

On 07/09/2013 10:47 AM, Ben Reser wrote: On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov wrote: I think it worth to release 1.8.1 without chunked requests proxy fixes: 1. We have 75 revisions merged to 1.8.x since 1.8.0. Some of them critical. (see attached file) 2. Discussion about chunked reques

RE: svn commit: r1501371 - /subversion/trunk/subversion/libsvn_ra_serf/util_error.c

> -Original Message- > From: danie...@apache.org [mailto:danie...@apache.org] > Sent: dinsdag 9 juli 2013 18:41 > To: comm...@subversion.apache.org > Subject: svn commit: r1501371 - > /subversion/trunk/subversion/libsvn_ra_serf/util_error.c > > Author: danielsh > Date: Tue Jul 9 16:41:2

Re: 1.8.1

On 09.07.2013 19:47, Ben Reser wrote: > On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov wrote: >> I think it worth to release 1.8.1 without chunked requests proxy fixes: >> 1. We have 75 revisions merged to 1.8.x since 1.8.0. Some of them >> critical. (see attached file) >> 2. Discussion about chunke

RE: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

> -Original Message- > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 9 juli 2013 18:39 > To: dev@subversion.apache.org > Cc: comm...@subversion.apache.org > Subject: Re: svn commit: r1501049 - in /subversion/trunk/subversion: > include/svn_error_codes.h libsvn_ra_

Re: Updatable svn export

Ben Reser wrote on Tue, Jul 09, 2013 at 09:17:51 -0700: > On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf wrote: > > David Schweikert wrote on Thu, Jul 04, 2013 at 15:04:34 +0200: > >> I was thinking that we could use something like a "svn update > >> --readonly", where svn doesn't any check anythin

Re: 1.8.1

On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov wrote: > I think it worth to release 1.8.1 without chunked requests proxy fixes: > 1. We have 75 revisions merged to 1.8.x since 1.8.0. Some of them > critical. (see attached file) > 2. Discussion about chunked requests fixes is still going and it's > b

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On Tue, Jul 9, 2013 at 1:25 AM, Stefan Sperling wrote: > On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote: >> The option doesn't seem like a big barrier when you're applying it to >> a handful of machines for yourself. Scale that effort up to a user >> base of 20,000 users and the option

Re: 1.8.1

On Tue, Jul 9, 2013 at 6:00 AM, Ben Reser wrote: > On Mon, Jul 8, 2013 at 8:17 AM, Ben Reser wrote: >> Just a nudge to everyone to take a look at STATUS so I can cut the >> tarball later today. I'll be working through STATUS myself today and >> will be on IRC giving people a chance to get their

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

On Tue, Jul 9, 2013 at 12:55 AM, Ben Reser wrote: > Have we considered just turning off chunked requests entirely until > Serf has a fix to automatically detect and handle servers that don't > support chunked requests? I've seen a lot of discussion about the > cost of doing an extra round trip to

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

Daniel Shahaf wrote on Tue, Jul 09, 2013 at 16:20:56 +: > I accept that some API users may depend on SVN_ERR_RA_SERF_WRAPPED_ERROR. Do > you think it is a problem to assign that new meaning to it in 1.8.x? I reused > it for the same reasons you re-used an existing error code in r1498851, if y

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

On Tue, Jul 09, 2013 at 04:47:36PM +0200, Bert Huijben wrote: > > > > -Original Message- > > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > > Sent: dinsdag 9 juli 2013 16:12 > > To: Bert Huijben > > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > > Subject: Re: sv

Re: Updatable svn export

On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf wrote: > David Schweikert wrote on Thu, Jul 04, 2013 at 15:04:34 +0200: >> I was thinking that we could use something like a "svn update >> --readonly", where svn doesn't any check anything on the working copy, >> but just applies any changes committed

RE: Updatable svn export

> -Original Message- > From: Markus Schaber [mailto:m.scha...@codesys.com] > Sent: dinsdag 9 juli 2013 17:09 > To: Daniel Shahaf; David Schweikert > Cc: dev@subversion.apache.org > Subject: AW: Updatable svn export > > Hi, > > Von: Daniel Shahaf [mailto:danie...@elego.de] > > > David S

AW: Updatable svn export

Hi, Von: Daniel Shahaf [mailto:danie...@elego.de] > David Schweikert wrote on Thu, Jul 04, 2013 at 15:04:34 +0200: > > I was thinking that we could use something like a "svn update > > --readonly", where svn doesn't any check anything on the working copy, > > but just applies any changes committe

AW: Updatable svn export

Hi, David, Von: David Schweikert [mailto:da...@schweikert.ch] > We have a svn repository with many files (more than 30'000), and need to have > the HEAD version exported to a filesystem, whenever a commit is done. > > Currently, we have implemented this with a post-commit script that does a > "sv

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

On Tue, Jul 09, 2013 at 05:12:23PM +0300, 'Daniel Shahaf' wrote: > Bert Huijben wrote on Tue, Jul 09, 2013 at 15:34:56 +0200: > > The tens of thousands of Windows defined error codes are not mapped by > > Subversion or apr either, but they are certainly useful for applications. We > > never documen

RE: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

> -Original Message- > From: 'Daniel Shahaf' [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 9 juli 2013 16:12 > To: Bert Huijben > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > Subject: Re: svn commit: r1501049 - in /subversion/trunk/subversion: > include/svn_error_code

subversion.apache.org/docs/swig-py ? Re: Perl bindings docstrings Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

Roderich Schupp wrote on Tue, Jul 09, 2013 at 09:18:56 +0200: > On Mon, Jul 8, 2013 at 5:32 PM, Ben Reser wrote: > > Unless someone has invented real AI I just don't see how you can automate > > this. > > But certainly one could whip up a simple Perl script (oder editor macros) to > spare us from

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

Bert Huijben wrote on Tue, Jul 09, 2013 at 15:34:56 +0200: > > > > -Original Message- > > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > > Sent: dinsdag 9 juli 2013 15:27 > > To: Bert Huijben > > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > > Subject: Re: svn com

RE: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: dinsdag 9 juli 2013 14:23 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1501163 - in /subversion/trunk/subversion: > include/private/svn_wc_private.h libsvn_client/checkout.c > l

Re: checkout_tests.py 12 (checkout_peg_rev_date) breaks on fast setups

Philip Martin wrote on Tue, Jul 09, 2013 at 10:12:35 +0100: > Daniel Shahaf writes: > > > Philip - would the following work on your machine? I'd be +1 on the > > r1496127 nomination in STATUS if the following patch were (commited to > > trunk and) added to it. > > > > In case it matters, the Pyt

RE: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

> -Original Message- > From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] > Sent: dinsdag 9 juli 2013 15:27 > To: Bert Huijben > Cc: dev@subversion.apache.org; comm...@subversion.apache.org > Subject: Re: svn commit: r1501049 - in /subversion/trunk/subversion: > include/svn_error_codes.

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

Can you please give me a little credit? The problem here is not that 120171 doesn't get stringified in maintainer mode. The problem here is that it is a number which _does not have_ a symbolic name in APR's or Subversion's API, so if an API user wants to code against it they need to either hard-c

Re: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

On Tue, Jul 9, 2013 at 4:20 PM, Bert Huijben wrote: >> -Original Message- >> From: danie...@apache.org [mailto:danie...@apache.org] >> Sent: dinsdag 9 juli 2013 04:38 >> To: comm...@subversion.apache.org >> Subject: svn commit: r1501049 - in /subversion/trunk/subversion: >> include/svn_err

Re: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

On Tue, Jul 09, 2013 at 01:48:22PM +0200, Bert Huijben wrote: > The proper fix would be: > > Running 'svn cleanup' > Or fixing the reason why he needs to run 'svn cleanup. > > Creating potentially obstructing working copies with less checking is never > a solution. Certainly not if we want to sta

Re: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

On Tue, Jul 09, 2013 at 12:39:30PM +0200, Bert Huijben wrote: > > > > -Original Message- > > From: Bert Huijben [mailto:b...@qqmail.nl] > > Sent: dinsdag 9 juli 2013 12:26 > > To: dev@subversion.apache.org; s...@apache.org > > Subject: RE: svn commit: r1501163 - in /subversion/trunk/subvers

RE: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

> -Original Message- > From: danie...@apache.org [mailto:danie...@apache.org] > Sent: dinsdag 9 juli 2013 04:38 > To: comm...@subversion.apache.org > Subject: svn commit: r1501049 - in /subversion/trunk/subversion: > include/svn_error_codes.h libsvn_ra_serf/util_error.c > > Author: danie

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

Lieven Govaerts writes: > First of all, because that's not guaranteed to be or stay that way. > Take for instance svnsync. It currently sends two non-pipelined > OPTIONS requests (to my surprise) from: > 1. svn_ra_serf__exchange_capabilities > 2. svn_ra_serf__v2_get_youngest_revnum > > I consider

RE: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

> -Original Message- > From: Stefan Sperling [mailto:s...@apache.org] > Sent: dinsdag 9 juli 2013 12:44 > To: Bert Huijben > Cc: dev@subversion.apache.org > Subject: Re: svn commit: r1501163 - in /subversion/trunk/subversion: > include/private/svn_wc_private.h libsvn_client/checkout.c > l

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

Hi Philip, On Tue, Jul 9, 2013 at 12:01 PM, Philip Martin wrote: > Lieven Govaerts writes: > >> Note, again: Serf will not have a feature to automatically detect that >> servers don't support chunked requests. Such a check is implemented in >> ra_serf with the extra OPTIONS request, there's no o

Re: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

On Tue, Jul 09, 2013 at 12:25:33PM +0200, Bert Huijben wrote: > I haven't tested this, but this currently appears to remove the safety net > around: > $ rm trunk > $ svn co URL trunk > (which would produce an error and now two working copies) Why shouldn't it produce two working copies? The inner

RE: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

> -Original Message- > From: Bert Huijben [mailto:b...@qqmail.nl] > Sent: dinsdag 9 juli 2013 12:26 > To: dev@subversion.apache.org; s...@apache.org > Subject: RE: svn commit: r1501163 - in /subversion/trunk/subversion: > include/private/svn_wc_private.h libsvn_client/checkout.c > libsvn_

RE: svn commit: r1501163 - in /subversion/trunk/subversion: include/private/svn_wc_private.h libsvn_client/checkout.c libsvn_wc/adm_files.c

> -Original Message- > From: s...@apache.org [mailto:s...@apache.org] > Sent: dinsdag 9 juli 2013 11:35 > To: comm...@subversion.apache.org > Subject: svn commit: r1501163 - in /subversion/trunk/subversion: > include/private/svn_wc_private.h libsvn_client/checkout.c > libsvn_wc/adm_files.

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

Lieven Govaerts writes: > Note, again: Serf will not have a feature to automatically detect that > servers don't support chunked requests. Such a check is implemented in > ra_serf with the extra OPTIONS request, there's no other way to do > this without the extra roundtrip. There is another way:

RE: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

> -Original Message- > From: Ben Reser [mailto:b...@reser.org] > Sent: dinsdag 9 juli 2013 09:46 > To: Greg Stein > Cc: kmradke; Subversion Development > Subject: Re: svn commit: r1495419 - in > /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c > > On Mon, Ju

RE: svn commit: r1501049 - in /subversion/trunk/subversion: include/svn_error_codes.h libsvn_ra_serf/util_error.c

> -Original Message- > From: danie...@apache.org [mailto:danie...@apache.org] > Sent: dinsdag 9 juli 2013 04:38 > To: comm...@subversion.apache.org > Subject: svn commit: r1501049 - in /subversion/trunk/subversion: > include/svn_error_codes.h libsvn_ra_serf/util_error.c > > Author: danie

Re: checkout_tests.py 12 (checkout_peg_rev_date) breaks on fast setups

Daniel Shahaf writes: > Philip - would the following work on your machine? I'd be +1 on the > r1496127 nomination in STATUS if the following patch were (commited to > trunk and) added to it. > > In case it matters, the Python version I tested it with is 2.6. 2.5 is the problem and I don't have

Re: svn commit: r1499747 - /subversion/trunk/subversion/tests/libsvn_wc/op-depth-test.c

"Bert Huijben" writes: >> @@ -1903,7 +1903,7 @@ check_db_actual(svn_test__sandbox_t* b, >> { >>const char *local_relpath >> = svn__apr_hash_index_key(apr_hash_first(b->pool, path_hash)); >> - return svn_error_createf(SVN_ERR_TEST_FAILED, >> svn_sqlite__close(sdb), >> +

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On Tue, Jul 09, 2013 at 12:45:49AM -0700, Ben Reser wrote: > The option doesn't seem like a big barrier when you're applying it to > a handful of machines for yourself. Scale that effort up to a user > base of 20,000 users and the option stops looking like a reasonable > response. Resolving the p

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

On Tue, Jul 9, 2013 at 9:55 AM, Ben Reser wrote: [..] > Have we considered just turning off chunked requests entirely until > Serf has a fix to automatically detect and handle servers that don't > support chunked requests? Note, again: Serf will not have a feature to automatically detect that ser

Re: svn commit: r1501038 - /subversion/branches/1.8.x/STATUS

On Mon, Jul 8, 2013 at 9:52 PM, Greg Stein wrote: > If you're going to vote this way, then I think you need to say what would > solve the issue for you. We probably don't want to play "bring me another > rock". I'm pretty sure that Daniel would accept my suggestion in the other thread of [[[ I'd

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

On Mon, Jul 8, 2013 at 8:53 PM, Greg Stein wrote: > For *this* project, that is absolutely the case. We have never said "let's > work against any server anybody decides to implement." We write to our > client, and our server, and third parties adapt to our changes. But we have said that a newer S

Re: Perl bindings docstrings Re: svn commit: r1488693 - /subversion/trunk/subversion/bindings/swig/perl/native/Client.pm

On Mon, Jul 8, 2013 at 5:32 PM, Ben Reser wrote: > > So it's as simple as "extract docstring from C header and reformat as > POD". > Actually I meant "So it's NOT as simple...", at least if you want to fully automate this. > Exactly this. We need this documentation. Sometimes we're behind on

AW: fsfs-format7 integration plan

Hi, Von: Ben Reser [mailto:b...@reser.org] > > On Tue, Jul 2, 2013 at 5:07 AM, Greg Stein wrote: > > As noted on IRC earlier, we just deprecated BDB so that we wouldn't > > have to continue supporting multiple backends. But it seems you have > > just created a third/new backend. > > I think tha