In-Repo-Authz

2012-12-18 Thread Ben Reser
I've finished the work needed to implement in-repo-authz on the branch. I'd like to merge this code back to trunk. If there are no objections I'll merge it into trunk next week. Please review my changes. You can view the overall set of changes that would be merged with: svn diff -x-p http://svn

Re: [PATCH] Fix for "\r" in "svnrdump load" (issue 4263) (reworked)

2012-12-18 Thread Ben Reser
On Tue, Dec 18, 2012 at 9:17 AM, Gabriela Gibson wrote: > [[[ > Fix issue #4263: svnrdump: E125005: Cannot accept non-LF line endings in > 'svn:log' property > > Fix to ensure that no "\r" characters are present in revision or node > props. > > In the case of "\r\n" character sequences, the "\r" i

Re: [PATCH] Fix for "\r" in "svnrdump load" (issue 4263)

2012-12-18 Thread Daniel Shahaf
Gabriela Gibson wrote on Tue, Dec 18, 2012 at 17:17:08 +: > I'll be taking a little break for a few days Enjoy! > and will be doing some more research into the suggested projects > before I ask on the list for advice as to which project to choose > next. Feel free to catch us on IRC, too,

Re: [PATCH] Fix for "\r" in "svnrdump load" (issue 4263) (reworked)

2012-12-18 Thread Gabriela Gibson
[[[ Fix issue #4263: svnrdump: E125005: Cannot accept non-LF line endings in 'svn:log' property Fix to ensure that no "\r" characters are present in revision or node props. In the case of "\r\n" character sequences, the "\r" is removed. In the case of "\r" characters which are not followed by "

Re: [PATCH] Fix for "\r" in "svnrdump load" (issue 4263)

2012-12-18 Thread Gabriela Gibson
On 18/12/12 02:09, Ben Reser wrote: On Mon, Dec 17, 2012 at 5:40 PM, Gabriela Gibson wrote: [[ Fix issue #4263: svnrdump: E125005: Cannot accept non-LF line endings in 'svn:log' property Fix to ensure that no "\r" characters are present in revision or node props. Looks pretty good to me with

Re: [RFC] New macro SVN_WC__DB_WITH_TXN(my_func_call(...)) doesn't need a baton

2012-12-18 Thread Julian Foad
I (Julian Foad) wrote: > The "call a function within a transaction" paradigm is used heavily in > wc_db.c.  [...]  To simplify it, we can write a statement > macro that takes a complete, arbitrary function call as an argument.  > [...] Then the usage looks like this: > >   /* ... */ >   static

Re: [PATCH] Improve error handling in svn_ra_serf__replay_range()

2012-12-18 Thread vijay
On Monday 17 December 2012 09:34 PM, Philip Martin wrote: vijay writes: The function svn_ra_serf__replay_range() doesn't return any error while running 'svnrdump dump -rN:M '[Issue #4100]. It behaves as if the dump completed successfully. * subversion/libsvn_ra_serf/replay.c (svn_ra_serf__

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Daniel Shahaf
Stefan Sperling wrote on Tue, Dec 18, 2012 at 11:27:25 +0100: > On Tue, Dec 18, 2012 at 12:19:02PM +0200, Daniel Shahaf wrote: > > Stefan Sperling wrote on Tue, Dec 18, 2012 at 11:03:56 +0100: > > > Why would you *not* want to do this? Don't say "because the bug isn't > > > in svn" since that is cl

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Stefan Sperling
On Tue, Dec 18, 2012 at 12:19:02PM +0200, Daniel Shahaf wrote: > Stefan Sperling wrote on Tue, Dec 18, 2012 at 11:03:56 +0100: > > Why would you *not* want to do this? Don't say "because the bug isn't > > in svn" since that is clear. We're not fixing a bug in 'svn'. We're > > making it work properl

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Daniel Shahaf
Stefan Sperling wrote on Tue, Dec 18, 2012 at 11:03:56 +0100: > Why would you *not* want to do this? Don't say "because the bug isn't > in svn" since that is clear. We're not fixing a bug in 'svn'. We're > making it work properly by default in more environments. I didn't say you should not apply t

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Stefan Sperling
On Tue, Dec 18, 2012 at 11:48:02AM +0200, Daniel Shahaf wrote: > Stefan Sperling wrote on Tue, Dec 18, 2012 at 09:54:08 +0100: > > On Tue, Dec 18, 2012 at 01:55:55AM +0200, Daniel Shahaf wrote: > > > Not sure. For unattended scripts, the only difference between passing > > > --non-interactive or n

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Daniel Shahaf
Stefan Sperling wrote on Tue, Dec 18, 2012 at 09:54:08 +0100: > On Tue, Dec 18, 2012 at 01:55:55AM +0200, Daniel Shahaf wrote: > > Not sure. For unattended scripts, the only difference between passing > > --non-interactive or not passing it is the error message they get, right? > > > > I mean, if

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Stefan Sperling
On Mon, Dec 17, 2012 at 09:39:49PM +0100, Stefan Sperling wrote: > The simple patch below implements it with the isatty() on *nix and > _isatty() on Windows (untested -- thanks for the hint Bert!). Updated version that adds --force-interactive for users who require the previous behaviour for whate

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Stefan Sperling
On Tue, Dec 18, 2012 at 09:54:08AM +0100, Stefan Sperling wrote: > I've seen this happen in Jenkins builds that run 'svn export' and > adding --non-interactive fixed it. Correction: I misrembered. This wasn't happening in Jenkins, but in an automated test environment ("SQS Test") which executes ba

Re: svn commit: r1422706 - in /subversion/trunk/subversion: libsvn_subr/opt.c tests/cmdline/svntest/main.py

2012-12-18 Thread Stefan Sperling
On Tue, Dec 18, 2012 at 01:55:55AM +0200, Daniel Shahaf wrote: > Not sure. For unattended scripts, the only difference between passing > --non-interactive or not passing it is the error message they get, right? > > I mean, if they pass it they will get "Cannot prompt because we aren't > interacti