Hi,
Von: Ben Reser [mailto:b...@reser.org]
On Tue, Jul 2, 2013 at 5:07 AM, Greg Stein gst...@gmail.com 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
On Mon, Jul 8, 2013 at 5:32 PM, Ben Reser b...@reser.org 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
On Mon, Jul 8, 2013 at 8:53 PM, Greg Stein gst...@gmail.com 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
On Mon, Jul 8, 2013 at 9:52 PM, Greg Stein gst...@gmail.com 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
On Tue, Jul 9, 2013 at 9:55 AM, Ben Reser b...@reser.org 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
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
Bert Huijben b...@qqmail.nl 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),
+
Daniel Shahaf danie...@elego.de 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
-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: danielsh
-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, Jul 8,
-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.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
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
Hi Philip,
On Tue, Jul 9, 2013 at 12:01 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Lieven Govaerts l...@apache.org 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
-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
Lieven Govaerts l...@apache.org 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
-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: danielsh
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/subversion:
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 start
On Tue, Jul 9, 2013 at 4:20 PM, Bert Huijben b...@qqmail.nl 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:
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
-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.h
Philip Martin wrote on Tue, Jul 09, 2013 at 10:12:35 +0100:
Daniel Shahaf danie...@elego.de 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,
-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
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 commit: r1501049
Roderich Schupp wrote on Tue, Jul 09, 2013 at 09:18:56 +0200:
On Mon, Jul 8, 2013 at 5:32 PM, Ben Reser b...@reser.org 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
-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_codes.h
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 documented
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
svn
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 committed since
-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 Schweikert
On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf danie...@elego.de 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
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: svn commit:
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 you
On Tue, Jul 9, 2013 at 12:55 AM, Ben Reser b...@reser.org 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
On Tue, Jul 9, 2013 at 6:00 AM, Ben Reser b...@reser.org wrote:
On Mon, Jul 8, 2013 at 8:17 AM, Ben Reser b...@reser.org 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
On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov i...@visualsvn.com 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
-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
On 09.07.2013 19:47, Ben Reser wrote:
On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov i...@visualsvn.com 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
-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:22 2013
On 07/09/2013 10:47 AM, Ben Reser wrote:
On Tue, Jul 9, 2013 at 10:12 AM, Ivan Zhakov i...@visualsvn.com 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
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
On Jul 9, 2013 12:52 PM, Ben Reser b...@reser.org wrote:
On Tue, Jul 9, 2013 at 12:55 AM, Ben Reser b...@reser.org 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
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: r1501049 - in
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 *d
-
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 the
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
-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
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 because API
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]
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 -
-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:
-Original
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
-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 would welcome
On Tue, Jul 9, 2013 at 7:33 PM, Ben Reser b...@reser.org wrote:
On Tue, Jul 9, 2013 at 1:25 AM, Stefan Sperling s...@elego.de 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
On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben b...@qqmail.nl 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 -
On Tue, Jul 9, 2013 at 1:44 PM, Johan Corveleyn jcor...@gmail.com 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
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 making
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
On Wed, Jul 10, 2013 at 02:52:21AM +0400, Ivan Zhakov wrote:
On Wed, Jul 10, 2013 at 1:51 AM, Bert Huijben b...@qqmail.nl 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
On Tue, Jul 9, 2013 at 4:40 PM, Daniel Shahaf d...@daniel.shahaf.name 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
On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf danie...@apache.org 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
On Tue, Jul 9, 2013 at 9:10 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf danie...@apache.org 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
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.
On Tue, Jul 09, 2013 at 09:13:07PM -0400, Greg Stein wrote:
On Tue, Jul 9, 2013 at 9:10 PM, Greg Stein gst...@gmail.com wrote:
On Tue, Jul 9, 2013 at 8:15 PM, Daniel Shahaf danie...@apache.org wrote:
...
So, I submit that your veto lacks a technical basis, and is therefore
invalid,
and
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
On 09.07.2013 05:53, Greg Stein wrote:
On Mon, Jul 8, 2013 at 9:52 PM, Ben Reser b...@reser.org
mailto:b...@reser.org 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
On Tue, Jul 9, 2013 at 9:48 PM, Daniel Shahaf danie...@apache.org 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
On Tue, Jul 9, 2013 at 6:48 PM, Daniel Shahaf danie...@apache.org 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
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
On Tue, Jul 9, 2013 at 8:04 PM, Joseph Schaefer joe_schae...@yahoo.com 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
On Tue, Jul 9, 2013 at 10:50 PM, Branko Čibej br...@wandisco.com 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
On Wed, Jul 10, 2013 at 5:33 AM, Stefan Sperling s...@elego.de 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
73 matches
Mail list logo
