Re: svn commit: r1872919 - /subversion/trunk/subversion/tests/libsvn_subr/mergeinfo-test.c
On 17.01.2020 19:00, Daniel Shahaf wrote:
> julianf...@apache.org wrote on Fri, Jan 17, 2020 at 14:54:46 -:
>> @@ -2089,18 +2130,22 @@ test_rangelist_merge_random_canonical_in
>> +if (failure_mode)
>>{
>> -printf("testcase FAIL: %s / %s\n",
>> +printf("first example of a failure mode: %s / %s\n"
>> + " %s\n",
>> rangelist_to_string(rlx, iterpool),
>> + rangelist_to_string(rly, iterpool),
>> + failure_mode);
> Test programs aren't supposed to print arbitrary stuff to stdout.
>
> Specifically, the interface between run_tests.py and the test programs
> specifies¹ that test programs shall only print "PASS:" and "FAIL:" lines by
> default. We could of course extend that to support printing of new info, for
> example, as "INFO:" lines. So would it make sense to prepend "INFO:" to that
> line?
We have test debugging with DBG: as the prefix.
-- Brane
Re: svn commit: r1869868 - /subversion/trunk/INSTALL
On 16.11.2019 00:41, Daniel Shahaf wrote: > hartmannat...@apache.org wrote on Fri, Nov 15, 2019 at 16:21:00 -: >> +++ subversion/trunk/INSTALL Fri Nov 15 16:20:59 2019 >> @@ -120,17 +120,17 @@ I.INTRODUCTION >> assembler modules of OpenSSL. As of OpenSSL 1.1.0 NASM is the >> only supported assembler. >> >> + * Berkeley DB (DEPRECATED and OPTIONAL for client and server) >> >> + When you create a repository, you have the option of >> + specifying a storage 'back-end' implementation. Currently, >> + there are two options. The newer and recommended one, known > There are three options: bdb, fsfs, fsx. (This error predates your change.) FSX is still experimental, is not tested by buildbots, was never "released" in an meaningful way and now I doubt it ever will be. -- Brane
Re: svn commit: r1868571 - /subversion/trunk/build/run_tests.py
On 18.10.2019 06:39, danie...@apache.org wrote:
> Author: danielsh
> Date: Fri Oct 18 04:39:08 2019
> New Revision: 1868571
>
> URL: http://svn.apache.org/viewvc?rev=1868571=rev
> Log:
> * build/run_tests.py
> (TestHarness.run): Tweak new output.
>
> Modified:
> subversion/trunk/build/run_tests.py
>
> Modified: subversion/trunk/build/run_tests.py
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/build/run_tests.py?rev=1868571=1868570=1868571=diff
> ==
> --- subversion/trunk/build/run_tests.py (original)
> +++ subversion/trunk/build/run_tests.py Fri Oct 18 04:39:08 2019
> @@ -716,11 +716,8 @@ class TestHarness:
>summary = "Some tests failed"
> else:
>summary = "All tests successful"
> -print("SUMMARY: %s, by the grace of Python %d.%d.%d.\n"
> - % (summary,
> - sys.version_info.major,
> - sys.version_info.minor,
> - sys.version_info.micro))
> +print("Python version: %d.%d.%d.\n" % sys.version_info[:3])
> +print(summary)
>
> self._close_log()
> return failed
I don't object to the changed message, but I do object to the missing
prefix "SUMMARY: " on the last line and the missing additional newline
on the same last line and the extra newline on the python version line.
Should be:
print("SUMMARY: %s\n" % summary)
and remove the trailing newline from the Python version line.
-- Brane
Re: svn commit: r1865987 - /subversion/trunk/subversion/libsvn_fs_fs/verify.c
On 29.08.2019 02:58, Daniel Shahaf wrote:
> br...@apache.org wrote on Tue, 27 Aug 2019 12:10 +00:00:
>> +++ subversion/trunk/subversion/libsvn_fs_fs/verify.c Tue Aug 27 12:10:43
>> 2019
>> @@ -694,8 +694,9 @@ compare_p2l_to_rev(svn_fs_t *fs,
>> return svn_error_createf(SVN_ERR_FS_INDEX_CORRUPTION,
>> NULL,
>> _("p2l index entry for changes in"
>> - " revision r%ld is item %ld of type"
>> - " %d at offset %s"),
>> + " revision r%ld is item"
>> + " %"APR_UINT64_T_FMT
>> + " of type %d at offset %s"),
> Preexisting problem: entry->type is an apr_uint32_t but formatted as %d.
>
> And with that fixed, backport?
Done, and done. Thanks.
-- Brane
Re: svn commit: r1817718 - /subversion/site/staging/docs/index.html / Reinstate 1.6 API docu
On 10.12.2017 17:00, Stefan wrote: > On 10/12/2017 16:54, luke1...@apache.org wrote: >> Author: luke1410 >> Date: Sun Dec 10 15:54:23 2017 >> New Revision: 1817718 >> >> URL: http://svn.apache.org/viewvc?rev=1817718=rev >> Log: >> * site/staging/docs/index.html: add a new section for unsupported versions >> and >> move the 1.7 links to that section. >> >> Modified: >> subversion/site/staging/docs/index.html >> >> Modified: subversion/site/staging/docs/index.html >> URL: >> http://svn.apache.org/viewvc/subversion/site/staging/docs/index.html?rev=1817718=1817717=1817718=diff >> == >> --- subversion/site/staging/docs/index.html (original) >> +++ subversion/site/staging/docs/index.html Sun Dec 10 15:54:23 2017 >> @@ -135,19 +135,6 @@ >> >> >> >> - >> -Subversion 1.7 >> -> -title="Link to this section"> >> - >> - >> - >> - C API >> - JavaHL >> - >> - >> - >> - >> >> Unreleased (1.10-dev) >> > @@ -175,6 +162,23 @@ >> >> >> >> + >> + >> +Archived releses >> + > +title="Link to this section"> >> + >> + >> +The following Subversion versions have reached their end of life. We >> still >> + provide the old documentation for archive/historical purposes. >> + >> + >> + Subversion 1.7 - C API >> + Subversion 1.7 - JavaHL >> + >> + >> + >> + >> >> >> >> > Based on the discussion with brane on IRC, I'd like to propose this > change to our API documentation and in principle add a new > unsupported-releases section where upon each release we move the old API > documentation of the then unsupported oldest release to. > > In addition, I'd like to reinstate the old 1.6 docu and add links to > these in this new section. The 1.6 docu was removed in r1696552 and now > results in old links to the 1.6 API docu no longer working (one example > being a link from the 1.6-release notes). Also I think it'd be quite > useful to keep the API documentation for unsupported versions still > laying around (it should not cause any significant resources keeping > them available, IMO). > > Note that I'd reinstate the old 1.6 docus directly on publish (rather > than on staging) since this would be easier to do (i.e. reverting the > corresponding changes from r1696552 which obviously were done on publish). > > Any objections and/or better ideas? Go ahead, as long as it's perfectly clear that the older releases are no longer supported. Your change on the staging site looks OK, except that: * "Archived releses" is not English :p * I suggest "Unsupported versions" instead -- Brane
Re: svn commit: r1805483 - /subversion/site/publish/docs/community-guide/releasing.part.html
On 19.08.2017 18:53, Daniel Shahaf wrote: > james...@apache.org wrote on Sat, 19 Aug 2017 02:44 +: >> -private@ list, in coördination with >> +private@ list, in coordination with > The diaeresis wasn't a typo. > > No need to revert this, just for future reference. I sort of understand kfogel's wish to resurrect the diaeresis, but would've spelled that "co-ordination" instead. :) -- Brane
Re: svn commit: r1801946 - in /subversion/trunk/subversion/libsvn_subr/lz4: LICENSE lz4.c lz4.h
On 14.07.2017 14:17, kot...@apache.org wrote: > Author: kotkov > Date: Fri Jul 14 12:17:20 2017 > New Revision: 1801946 > > * subversion/libsvn_subr/lz4/lz4.h: > Set svn:eol-style = native. > > * subversion/libsvn_subr/lz4/lz4.c: > Fix inconsistent EOLs, set svn:eol-style = native. Hmmm. Evgeny, don't you use a client that understands the svn:auto-props inherited property? On trunk: $ svn pg svn:auto-props . *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.hpp = svn:eol-style=native *.java = svn:eol-style=native ... At least your .c and .h files should've been added with correct eol-style ... -- Brane
Re: svn commit: r1748030 - /subversion/branches/authzperf/subversion/libsvn_repos/authz_parse.c
On 12.06.2016 19:45, stef...@apache.org wrote:
> Author: stefan2
> Date: Sun Jun 12 17:45:49 2016
> New Revision: 1748030
>
> URL: http://svn.apache.org/viewvc?rev=1748030=rev
> Log:
> On the authzperf branch:
> Make the authz parser accept "/" in repository names. The repository name
> may contain a relative path if the repo is located deeper down the file tree.
> The repository name still lives within a flat namespace - now simply allowing
> for '/' - and creates a separate namespace for in-repo paths.
>
> This fixes the svnsync tests.
>
> * subversion/libsvn_repos/authz_parse.c
> (rules_open_section): Remove the check for '/' in repository names.
>
> Modified:
> subversion/branches/authzperf/subversion/libsvn_repos/authz_parse.c
>
> Modified: subversion/branches/authzperf/subversion/libsvn_repos/authz_parse.c
> URL:
> http://svn.apache.org/viewvc/subversion/branches/authzperf/subversion/libsvn_repos/authz_parse.c?rev=1748030=1748029=1748030=diff
> ==
> --- subversion/branches/authzperf/subversion/libsvn_repos/authz_parse.c
> (original)
> +++ subversion/branches/authzperf/subversion/libsvn_repos/authz_parse.c Sun
> Jun 12 17:45:49 2016
> @@ -730,13 +730,6 @@ rules_open_section(void *baton, svn_stri
> _("Empty repository name in authz rule [%s]"),
> section->data);
>
> - if (memchr(rule, '/', repos_len))
> -return svn_error_createf(
> -SVN_ERR_AUTHZ_INVALID_CONFIG, NULL,
> -_("Invalid repository name '%s' in authz rule [%s]"),
> -apr_pstrmemdup(cb->parser_pool, rule, repos_len),
> -section->data);
> -
>acl.acl.rule.repos = intern_string(cb, rule, repos_len);
>rule = endp + 1;
>rule_len -= repos_len + 1;
Do we actually have reports of real-world cases where the limitation you
just removed was relevant? I can imagine this could only happen for
repositories that are served by svnserve, not mod_dav_svn, right?
-- Brane
Re: svn commit: r1740170 -/subversion/trunk/subversion/libsvn_client/conflicts.c
On 21.04.2016 09:24, Stefan Sperling wrote:
> On Wed, Apr 20, 2016 at 10:19:56PM +0200, Bert Huijben wrote:
>> The path calculation here 100% assumes that the working copy is always a
>> clean check out from ^/. This might be the case in our test suite, but in
>> almost every normal user scenario this isn’t the case.
>>
>> You can’t just calculate a repository root relative path ( ^/… ) from
>> dirents. You always need the repos_relpath from somewhere else.
>>
>> And once you start looking at switched files/directories, things get even
>> harder.
>>
>>
>> Bert
>>
> I'm not sure what you mean. Perhaps you're lacking some additional
> context for this diff?
>
> What's happening here is that we show a message like:
>
> delete X and copy ^/Y@Z here
>
> where X is a local conflicted path (taken from the local_abspath which is
> being resolved), Y is a repos-relpath stored in the conflict descriptor,
> and Z is a peg revision stored in the conflict descriptor.
>
> Assuming Y and Z were stored correctly when the conflict was created (the
> conflict resolver has no reason to assume otherwise), I don't see where
> this extrapolates a local path to a repostory path.
>
> Can you elaborate? Are you saying that's wrong to say "delete X" because
> X might not come from path ^/somewhere/X in the repository?
It is wrong to use conflict->local_abspath to construct the relative
URL. In general the local path bears no relation to the location in the
repository.
-- Brane
>> From: s...@apache.org
>> Sent: woensdag 20 april 2016 19:05
>> To: commits@subversion.apache.org
>> Subject: svn commit: r1740170
>> -/subversion/trunk/subversion/libsvn_client/conflicts.c
>>
>> Author: stsp
>> Date: Wed Apr 20 17:05:04 2016
>> New Revision: 1740170
>>
>> URL: http://svn.apache.org/viewvc?rev=1740170=rev
>> Log:
>> * subversion/libsvn_client/conflicts.c
>> (configure_option_merge_incoming_added_file_replace): Tweak this resolution
>>option's description slightly.
>>
>> Modified:
>> subversion/trunk/subversion/libsvn_client/conflicts.c
>>
>> Modified: subversion/trunk/subversion/libsvn_client/conflicts.c
>> URL:
>> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/conflicts.c?rev=1740170=1740169=1740170=diff
>> ==
>> --- subversion/trunk/subversion/libsvn_client/conflicts.c (original)
>> +++ subversion/trunk/subversion/libsvn_client/conflicts.c Wed Apr 20
>> 17:05:04 2016
>> @@ -4527,7 +4527,7 @@ configure_option_merge_incoming_added_fi
>> conflict->local_abspath, scratch_pool,
>> scratch_pool));
>>option->description =
>> -apr_psprintf(options->pool, _("delete '%s', copy '^/%s@%ld' here"),
>> +apr_psprintf(options->pool, _("delete '%s' and copy '^/%s@%ld'
>> here"),
>> svn_dirent_local_style(
>> svn_dirent_skip_ancestor(wcroot_abspath,
>> conflict->local_abspath),
>>
>>
>>
Re: svn commit: r1712223 - /subversion/trunk/subversion/mod_dav_svn/util.c
On 03.11.2015 09:12, i...@apache.org wrote: > Author: ivan > Date: Tue Nov 3 08:12:36 2015 > New Revision: 1712223 > > URL: http://svn.apache.org/viewvc?rev=1712223=rev > Log: > Do not insert newlines in base64 encoded responses in mod_dav_svn. This is > slightly reduce CPU usage on the client since it could decode responses with > bigger chunks instead line-by-line. This looks like one of those micro-optimisations that you like to complain about ... does it really make a measurable difference? A sane Base64 decoder should just ignore any newlines in the encoded stream and not try to split it into lines first. If our decoder /does/ read the response line-by-line, then I propose that's a better place for a performance improving fix. The (minor) downside of your change is that it makes it just a bit harder to read wire dumps. -- Brane
Re: svn commit: r1689214 - /subversion/trunk/CHANGES
On 05.07.2015 07:25, Bert Huijben wrote: That latest ‘status’ fix is about mod_status; and a new in 1.9 feature if I remember correctly. ‘svn status’ is 100% unaffected. Aargh. Thanks for the heads-up; it's really inconvenient to update CHANGES after the fact from logs and diffs. Will fix. -- Brane Bert Sent from Surface *From:* Branko Čibej mailto:br...@apache.org *Sent:* Sunday, July 5, 2015 7:06 AM *To:* commits@subversion.apache.org mailto:commits@subversion.apache.org Author: brane Date: Sun Jul 5 05:06:14 2015 New Revision: 1689214 URL: http://svn.apache.org/r1689214 Log: * CHANGES: Update for 1.9.0-RC3 Modified: subversion/trunk/CHANGES Modified: subversion/trunk/CHANGES URL: http://svn.apache.org/viewvc/subversion/trunk/CHANGES?rev=1689214r1=1689213r2=1689214view=diff == --- subversion/trunk/CHANGES (original) +++ subversion/trunk/CHANGES Sun Jul 5 05:06:14 2015 @@ -306,6 +306,9 @@ http://svn.apache.org/repos/asf/subversi * merge: raise a tree conflict on root of obstructing dir (r190) * cp: fix 'svn cp ^/A/D/H@1 ^/A' to properly create A (r1674455, r1674456) * status: fix incorrect output with file externals (issue #4580) +* status: fix crash on platforms that don't support C99 format + specifiers for strftime (r1683387) +* merge: fix part of issue #4582 (r1686175, r1687029, r1688258) - Server-side bugfixes: * svnserve: don't ignore socket initialization errors (r1544253) @@ -390,6 +393,9 @@ http://svn.apache.org/repos/asf/subversi * fsfs: fix 'EOF found' error when reading repo (issue #4577) * svnadmin freeze: unlock rep-cache.db as part of unfreezing (r1679169, r1679287) +* fsfs: improve stability in the presence of power or network + disk failures during 'svnadmin pack' (r1683378) +* detect invalid svndiff data earlier (r1684077) - Client-side and server-side bugfixes: * use less memory when retrieving extension from filename (r1548480) @@ -443,6 +449,7 @@ http://svn.apache.org/repos/asf/subversi * bash_completion: stop offering deprecated options (r1662291) * bash_completion: add '--show-item' and '--no-newline' (r1662622) * svnbench: add null-blame command (r1673785, r1673803, r1674015) +* svnbench: install with default 'make install' (r1685085) Developer-visible changes: - General: @@ -518,6 +525,9 @@ http://svn.apache.org/repos/asf/subversi characters that must be escaped when used in a URL. (r1664997) * fix breakage of the serf ra session with svn_ra_get_dir2() and svn_ra_get_log2(). (r1665213, r1665259, r1665609) +* resolve a race condition in some test suite cleanup code (r1683303) +* fix some tests on non-US default locale on Windows (r1684034) +* document the meaning of XFAIL for users building from source (r1683071) - API changes: * new RA callbacks for managing ra_svn tunnels: @@ -644,6 +654,7 @@ http://svn.apache.org/repos/asf/subversi * svn_ra_get_file_revs2() now handles SVN_INVALID_REVNUM as HEAD (r1660463) * new API svn_error_quick_wrapf() (r1662668) * new API svn_fs_node_has_props() (r1673170, r1673172, r1673692, r1673746) +* new API svn_repos_verify_fs3() (r1492651 ... r1687769) - Bindings: * javahl: add support for the RA layer (r1494650 et al) @@ -720,6 +731,7 @@ http://svn.apache.org/repos/asf/subversi with newer versions of SWIG (1675149) * javahl: requires Java 1.6 (r1677003) * javahl: on OS X use /usr/libexec/java_home to find the JDK (r1675774) +* javahl: allow compiling with a C++11 compiler (r1684412) Version 1.8.13
Re: svn commit: r1684678 - /subversion/trunk/subversion/libsvn_delta/svndiff.c
On 10.06.2015 16:09, kot...@apache.org wrote: Author: kotkov Date: Wed Jun 10 14:09:39 2015 New Revision: 1684678 URL: http://svn.apache.org/r1684678 Log: * subversion/libsvn_delta/svndiff.c (write_handler): Fix a small typo in the comment. Modified: subversion/trunk/subversion/libsvn_delta/svndiff.c Modified: subversion/trunk/subversion/libsvn_delta/svndiff.c URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_delta/svndiff.c?rev=1684678r1=1684677r2=1684678view=diff == --- subversion/trunk/subversion/libsvn_delta/svndiff.c (original) +++ subversion/trunk/subversion/libsvn_delta/svndiff.c Wed Jun 10 14:09:39 2015 @@ -687,7 +687,7 @@ write_handler(void *baton, /* At this point we processed all integral windows and DB-BUFFER is empty or contains partially read window header. - Check that unprocessed data is not larger that theoretical maximum + Check that unprocessed data is not larger than theoretical maximum s/data is/data are/. The noun data is plural, the singular is datum. Now exiting nitpicking mode. :) -- Brane
Re: svn commit: r1676535 - /subversion/trunk/subversion/tests/libsvn_subr/io-test.c
On 28.04.2015 15:45, i...@apache.org wrote: Author: ivan Date: Tue Apr 28 13:45:42 2015 New Revision: 1676535 URL: http://svn.apache.org/r1676535 Log: Follow-up to r1676526: Close install_stream in test. * subversion/tests/libsvn_subr/io-test.c (test_install_stream_to_longpath): Close stream before calling svn_stream__install_stream(). Modified: subversion/trunk/subversion/tests/libsvn_subr/io-test.c Modified: subversion/trunk/subversion/tests/libsvn_subr/io-test.c URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/libsvn_subr/io-test.c?rev=1676535r1=1676534r2=1676535view=diff == --- subversion/trunk/subversion/tests/libsvn_subr/io-test.c (original) +++ subversion/trunk/subversion/tests/libsvn_subr/io-test.c Tue Apr 28 13:45:42 2015 @@ -768,6 +768,7 @@ test_install_stream_to_longpath(apr_pool final_abspath = svn_dirent_join(deep_dir, stream1, pool); SVN_ERR(svn_stream__create_for_install(stream, deep_dir, pool, pool)); SVN_ERR(svn_stream_puts(stream, stream1 content)); + SVN_ERR(svn_stream_close(stream)); SVN_ERR(svn_stream__install_stream(stream, final_abspath, TRUE, Um, surely that can't be right? Using the stream after it's been closed? -- Brane
Re: svn commit: r1674628 - /subversion/branches/1.9.x/STATUS
On 19.04.2015 10:57, Bert Huijben wrote: Why do you set the header if you can just set the parsed depth value even more locally as I did in my patch I sent as reply on the thread? The patch Greg and Stefan cooked up kicks in a lot earlier in the request processing flow, and by modifying the request record instead of some internal structure it's more future-proof. IMO, that's a good thing. -- Brane
Re: svn commit: r1655821 - in /subversion/trunk/subversion: libsvn_ra_serf/options.c tests/cmdline/redirect_tests.py
On 29.01.2015 20:27, phi...@apache.org wrote:
Author: philip
Date: Thu Jan 29 19:27:19 2015
New Revision: 1655821
URL: http://svn.apache.org/r1655821
Log:
Distingush between permanent and temporary redirections to match the
1.8 behaviour.
* subversion/libsvn_ra_serf/options.c
(svn_ra_serf__exchange_capabilities): Permanent or temporary error.
* subversion/tests/cmdline/redirect_tests.py
(redirected_copy): Extend with temporary redirect.
Modified:
subversion/trunk/subversion/libsvn_ra_serf/options.c
subversion/trunk/subversion/tests/cmdline/redirect_tests.py
Modified: subversion/trunk/subversion/libsvn_ra_serf/options.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_serf/options.c?rev=1655821r1=1655820r2=1655821view=diff
==
--- subversion/trunk/subversion/libsvn_ra_serf/options.c (original)
+++ subversion/trunk/subversion/libsvn_ra_serf/options.c Thu Jan 29 19:27:19
2015
@@ -555,8 +555,9 @@ svn_ra_serf__exchange_capabilities(svn_r
opt_ctx-handler-sline.code 399)
{
return svn_error_createf(SVN_ERR_RA_SESSION_URL_MISMATCH, NULL,
- _(The repository reports that it was moved
-to '%s'),
+ (opt_ctx-handler-sline.code == 301
+? _(Repository moved permanently to '%s')
+: _(Repository moved temporarily to '%s')),
opt_ctx-handler-location);
}
I just noticed that we're probably handling the 307 status incorrectly,
or not at all.
-- Brane
Re: svn commit: r1637826 - /subversion/trunk/autogen.sh
On 02.12.2014 23:51, Ben Reser wrote:
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 the LIBTOOL_M4 environment
variable)
@@ -92,7 +92,7 @@ for file in ltoptions.m4 ltsugar.m4 ltve
rm -f build/$file
if [ $lt_major_version -ge 2 ]; then
-ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`/$file}
+ltfile=${LIBTOOL_M4-`cd $ltpath/../share/aclocal ; pwd`}/$file
if [ ! -f $ltfile ]; then
echo $ltfile not found (try setting the LIBTOOL_M4 environment
variable)
@@ -106,7 +106,7 @@ done
if [ $lt_major_version -ge 2 ]; then
for file in config.guess config.sub; do
-configfile=${LIBTOOL_CONFIG-`cd $ltpath/../share/libtool/config ;
pwd`/$file}
+configfile=${LIBTOOL_CONFIG-`cd $ltpath/../share/libtool/config ;
pwd`}/$file
if [ ! -f $configfile ]; then
echo $configfile not found (try setting the LIBTOOL_CONFIG
environment variable)
I know this isn't new to this particular change, but shouldn't these parameter
substitutions with defaults be using :- instead of just -? Because if you set
the variables to null then it'll be looking for these files in the root path.
Consider the following examples:
[[[
variable=
# variable has been declared, but is set to null.
echo ${variable-0}# (no output)
echo ${variable:-1} # 1
# ^
unset variable
echo ${variable-2}# 2
echo ${variable:-3} # 3
]]]
Seems to me the omission of the colon is a mistake here.
It may be a mistake; but, on the other hand, if someone sets
LIBTOOL_CONFIG or LIBTOOL_M4 to an empty string, it's not like it's the
end of the world. Unless they have a really weird setup, autogen.sh will
most likely fail; but that's as bad as it gets. You could even interpret
this as a feature of the script. :)
I don't mind changing this on trunk, but I think it wouldn't make sense
to backport; unless we also backported the other trunk changes (looking
in build-aux by default, etc.).
-- Brane
Re: svn commit: r1622946 - /subversion/trunk/subversion/libsvn_fs_fs/rev_file.c
On 07.09.2014 00:01, stef...@apache.org wrote: --- subversion/trunk/subversion/libsvn_fs_fs/rev_file.c (original) +++ subversion/trunk/subversion/libsvn_fs_fs/rev_file.c Sat Sep 6 22:01:09 2014 @@ -176,6 +176,9 @@ open_pack_or_rev_file(svn_fs_fs__revisio /* We failed for the first time. Refresh cache retry. */ SVN_ERR(svn_fs_fs__update_min_unpacked_rev(fs, scratch_pool)); + file-start_revision = rev ffd-min_unpacked_rev +? rev - (rev % ffd-max_files_per_dir) +: rev; Even though the precedence rules make this assignment behave as intended, I would really, really prefer to have parentheses around the ternary expression. -- Brane
Re: svn commit: r1614703 - in /subversion/branches/authzperf: BRANCH-README subversion/include/svn_string.h subversion/libsvn_repos/authz.c subversion/libsvn_subr/string.c
On 30.07.2014 18:27, stef...@apache.org wrote:
Author: stefan2
Date: Wed Jul 30 16:27:44 2014
New Revision: 1614703
+ for ( ; pos; pos = strstr(str-data + current, to_find), ++replacements)
+{
+ apr_size_t to_copy = pos - str-data - current;
This declaration shadows the one a few lines further up.
Stefan^2 , are you compiling in maintainer mode? If not, please do; If
yes, please make sure you don't commit code that cause new warnings.
They're really very distracting. Currently about 3/4 of all warnings
(using gcc and/or clang) are emitted from code you wrote.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco | Realising the impossibilities of Big Data
e. br...@wandisco.com
Re: svn commit: r1573106 - /subversion/trunk/build/ac-macros/compiler.m4
On 28.02.2014 23:57, phi...@apache.org wrote:
Author: philip
Date: Fri Feb 28 22:57:24 2014
New Revision: 1573106
URL: http://svn.apache.org/r1573106
Log:
* build/ac-macros/compiler.m4
(_SVN_XXFLAGS_ADD_IFELSE): Compile and link to test flag.
Modified:
subversion/trunk/build/ac-macros/compiler.m4
Modified: subversion/trunk/build/ac-macros/compiler.m4
URL:
http://svn.apache.org/viewvc/subversion/trunk/build/ac-macros/compiler.m4?rev=1573106r1=1573105r2=1573106view=diff
==
--- subversion/trunk/build/ac-macros/compiler.m4 (original)
+++ subversion/trunk/build/ac-macros/compiler.m4 Fri Feb 28 22:57:24 2014
@@ -35,7 +35,10 @@ AC_DEFUN([_SVN_XXFLAGS_ADD_IFELSE],
AC_LANG_PUSH([$1])
AC_MSG_CHECKING([if [$][$2] accepts $4])
[$3]=$4 [$][$3]
- AC_COMPILE_IFELSE([AC_LANG_SOURCE([[]])],[
+ dnl Compiling is not enough: Solaris cc accepts invalid options at
+ dnl compile-time and just warns, assuming they are for the linker,
+ dnl but they cause errors at link-time.
+ AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(){return 0;}]])]
This bit of source is not valid C90. It should be: int main(void){ ... }
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
Re: svn commit: r1563991 - /subversion/trunk/subversion/libsvn_ra_serf/update.c
On 03.02.2014 19:07, bre...@apache.org wrote: Author: breser Date: Mon Feb 3 18:07:55 2014 New Revision: 1563991 URL: http://svn.apache.org/r1563991 Log: Fix a compiler warning by removing some pointless code. * subversion/libsvn_ra_serf/update.c (body_allocate_all): Remove test for sz = 0, apr_size_t is not signed so it will always be true. Well, yes, but I guess the original intent was to optimize the code by not performing a no-op memcpy. Now you can decide to go the academic route and replace the sz = 0 with sz 0, or be more practical and assume the compiler will inline memcpy anyway, and the additional check of the size will get optimized out. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Question on mergeinfo added in r1500370 Re: svn commit: r1500370 [1/5]
On 07.07.2013 15:46, Daniel Shahaf wrote: On Sun, Jul 07, 2013 at 05:06:51AM -, br...@apache.org wrote: Author: brane Date: Sun Jul 7 05:06:50 2013 New Revision: 1500370 URL: http://svn.apache.org/r1500370 Log: On the javahl-1.8-extensions branch: Sync JavaHL with trunk up to r1500364. Sync with branches/1.8.x up to r1500366. Propchange: subversion/branches/javahl-1.8-extensions/ -- Merged /subversion/branches/1.8.x:r1494631-1500366 Merged /subversion/trunk:r1478987,1480080,1481772,1481847,1489339,1490684,1491432,1491707,1492020,1492148,1492264,1493424,1493475,1493703,1493720,1494171,1494223,1494287,1494298,1494318,1494342,1494913,1494967,1495104,1495428,1495432,1495446,1495850,1496110,1496132,1496151,1496938,1496957,1497002,1497318-1497319,1497551,1497804,1498136,1498456,1498550,1498564,1499095-1499096,1499727,1500226 Why does the output show one contiguous range for 1.8.x, but a series of cherry-picks for trunk? Because changes from trunk were cherry-picked to 1.8.x, and I make a wholesale sync from 1.8.x to the JavaHL extensions branch. The trunk mergeinfo is inherited from the 1.8.x branch. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn commit: r1499034 - /subversion/trunk/build/ac-macros/sqlite.m4
On 02.07.2013 19:44, danie...@apache.org wrote: Author: danielsh Date: Tue Jul 2 17:44:58 2013 New Revision: 1499034 URL: http://svn.apache.org/r1499034 Log: * build/ac-macros/sqlite.m4 (SVN_LIB_SQLITE.--with-sqlite): Look for sqlite-amalgamation in the build dir, too. (SVN_DOWNLOAD_SQLITE): Adjust error message accordingly. Doesn't that kind of conflict with get-deps.sh? -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn commit: r1492044 - in /subversion/branches/1.8.x: ./ STATUS win-tests.py
On 12.06.2013 14:13, Ivan Zhakov wrote: On Wed, Jun 12, 2013 at 1:57 PM, Ben Reser b...@reser.org wrote: Kinda wish we hadn't merged this into 1.8.x. Unless we revert this means there will be changes to the 1.8.0 tarball from rc3. I'm fine with that, but I'm not sure I would have done it for just this change since it increases the testing that has to be done (at least one Windows) for the final 1.8.0 files. So far this is the only change from rc3 to 1.8.0 final. I moved this revision to the approved section, but I was thinking that we disabled automatic svn-role backporting. Anyway I think this revision should be in 1.8.0: otherwise test suite cannot be started without manual tweaks. Messing with a release candidate for the sake of a couple minor test suite tweaks is not my idea of sane release management. In other words, -1 to putting this in 1.8.0. Instead, I propose we revert that change and explain how to run Windows tests in the release notes. We can then reintroduce the change in 1.8.1; it's not as if the test suite scripts have anything to do with binary compatibility. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: svn commit: r1486463 - in /subversion/trunk/tools/server-side/svnpubsub: revprop-change-hook.py svnpubsub/client.py svnpubsub/server.py watcher.py
On 27.05.2013 06:41, Daniel Shahaf wrote:
On Sun, May 26, 2013 at 09:22:48PM +, Daniel Shahaf wrote:
On Sun, May 26, 2013 at 08:06:47PM -, br...@apache.org wrote:
+def main(repo, revision, author, propname, action):
+else:
+sys.stderr.write('Unknown revprop change action %s\n' % action)
+return
Maybe sys.exit(1)? Otherwise the stderr output will likely go unnoticed
(libsvn_repos discards stderr when the exit code is zero).
You haven't s/return/sys.exit(1)/ here. Do you disagree with that change?
Ah, I just missed it. It was kind of late.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1483292 - in /subversion/trunk/subversion: include/private/svn_string_private.h libsvn_subr/string.c libsvn_subr/types.c
On 16.05.2013 12:19, stef...@apache.org wrote:
Author: stefan2
Date: Thu May 16 10:19:18 2013
New Revision: 1483292
URL: http://svn.apache.org/r1483292
Log:
Daring another no-no: provide our own, optimized implementation
of a string to unsigned int conversion. Use it to simplify speed up
svn_revnum_parse.
Background: In my 'svn log -g' tests, I found that 50% of the runtime
is spent parsing mergeinfo and ~20% in strtol alone.
* subversion/include/private/svn_string_private.h
(svn__strtoff): declare new private API
* subversion/libsvn_subr/string.c
(svn__strtoff): implement it
* subversion/libsvn_subr/types.c
(svn_revnum_parse): use it
Modified:
subversion/trunk/subversion/include/private/svn_string_private.h
subversion/trunk/subversion/libsvn_subr/string.c
subversion/trunk/subversion/libsvn_subr/types.c
Modified: subversion/trunk/subversion/include/private/svn_string_private.h
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/include/private/svn_string_private.h?rev=1483292r1=1483291r2=1483292view=diff
==
--- subversion/trunk/subversion/include/private/svn_string_private.h
(original)
+++ subversion/trunk/subversion/include/private/svn_string_private.h Thu May
16 10:19:18 2013
@@ -136,6 +136,12 @@ svn_stringbuf__morph_into_string(svn_str
apr_status_t
svn__strtoff(apr_off_t *offset, const char *buf, char **end, int base);
+/** Like strtoul but with a fixed base of 10. This allows the compiler to
+ * generate massively faster (4x on 64bit LINUX) code.
+ */
+unsigned long
+svn__strtoul(const char *buffer, char **end);
+
/** Number of chars needed to represent signed (19 places + sign + NUL) or
* unsigned (20 places + NUL) integers as strings.
*/
Modified: subversion/trunk/subversion/libsvn_subr/string.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_subr/string.c?rev=1483292r1=1483291r2=1483292view=diff
==
--- subversion/trunk/subversion/libsvn_subr/string.c (original)
+++ subversion/trunk/subversion/libsvn_subr/string.c Thu May 16 10:19:18 2013
@@ -1027,6 +1027,36 @@ svn__strtoff(apr_off_t *offset, const ch
#endif
}
+unsigned long
+svn__strtoul(const char *buffer, char **end)
+{
+ unsigned long result = 0;
+
+ /* this loop will execute in just 2 CPU cycles, confirmed by measurement:
+ 7 macro-ops (max 4 / cycle = 2 cycles)
You know, I really don't find these kinds of comments very helpful
unless they also say that they're specific to one particular version of
a particular CPU architecture ...
+ 1 load (max 1 / cycle)
+ 1 jumps (compare + conditional jump == 1 macro op; max 1 / cycle)
+ 2 arithmetic ops (subtract, increment; max 3 / cycle)
+ 2 scale-and-add AGU ops (max 3 / cycle)
+ 1 compiler-generated move operation
+ dependency chain: temp = result * 4 + result; result = temp * 2 + c
+ (2 ops with latency 1 = 2 cycles)
+ */
+ while (1)
+{
+ unsigned long c = *buffer - '0';
+ if (c 9)
+break;
+
+ result = result * 10 + c;
+ ++buffer;
+}
+
+ *end = (char *)buffer;
And this is why I prefer not to reimplement library functions. Why is
'end' a 'char**' and not a 'char *const *'? I always felt the strtol
signature was massively broken because of that.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1464985 - in /subversion/trunk/subversion: svnadmin/svnadmin.c tests/cmdline/svntest/main.py
On 06.04.2013 05:14, Ben Reser wrote:
On Fri, Apr 5, 2013 at 7:11 AM, br...@apache.org wrote:
Author: brane
Date: Fri Apr 5 14:11:49 2013
New Revision: 1464985
URL: http://svn.apache.org/r1464985
Log:
Make svnadmin create --fs-type=bdb warn about the BDB back-end deprecation.
* subversion/svnadmin/svnadmin.c (subcommand_create): Print a warning to
stderr
if the requested filesystem type is bdb.
* subversion/tests/cmdline/svntest/main.py (create_repos): Expect the output
of svnadmin create to contain that warning.
I actually started doing this today while I was on a plane since you
hadn't gotten around to it.
My code ended up looking very similar to yours:
[[[
/* With 1.8 we are announcing that BDB is deprecated. No support
* has been removed and it will continue to work until some future
* date. The purpose here is to discourage people from creating
* new BDB repositories which they will need to dump/load into
* FSFS or some new FS type in the future. */
if (0 == strcmp(opt_state-fs_type, SVN_FS_TYPE_BDB))
{
SVN_ERR(svn_cmdline_fprintf(stderr, pool, _(%swarning: FS type
'%s'
has been
deprecated\n),
svnadmin: , opt_state-fs_type));
fflush(stderr);
}
svn_hash_sets(fs_config, SVN_FS_CONFIG_FS_TYPE, opt_state-fs_type);
]]]
I've gone ahead and wrapped the error string in _() so it can be
translated and switched to using the constants for the fs type strings
in r1465170.
I didn't end up using svn_handle_warning2() because it just felt dirty
to build a svn_error_t just to print a warning (especially since
producing global pools is so slow). Nor did a generic warning code
seem useful. But I'm not going to change it now unless you agree.
I did like your fsfs suggestion though.
In many ways your change is better than mine. So if you don't mind, I'll
merge the two (and adjust the test infrastructure accordingly).
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1463922 - /subversion/trunk/subversion/libsvn_repos/hooks.c
On 03.04.2013 13:21, phi...@apache.org wrote:
Author: philip
Date: Wed Apr 3 11:21:29 2013
New Revision: 1463922
URL: http://svn.apache.org/r1463922
Log:
* subversion/libsvn_repos/hooks.c (parse_hooks_env): Remove unused variable.
Modified:
subversion/trunk/subversion/libsvn_repos/hooks.c
Modified: subversion/trunk/subversion/libsvn_repos/hooks.c
URL:
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_repos/hooks.c?rev=1463922r1=1463921r2=1463922view=diff
==
--- subversion/trunk/subversion/libsvn_repos/hooks.c (original)
+++ subversion/trunk/subversion/libsvn_repos/hooks.c Wed Apr 3 11:21:29 2013
@@ -418,7 +418,6 @@ parse_hooks_env(apr_hash_t **hooks_env_p
apr_pool_t *scratch_pool)
{
svn_config_t *cfg;
- int n;
struct parse_hooks_env_section_baton b;
if (local_abspath)
@@ -426,8 +425,8 @@ parse_hooks_env(apr_hash_t **hooks_env_p
SVN_ERR(svn_config_read2(cfg, local_abspath, FALSE, TRUE,
scratch_pool));
b.cfg = cfg;
b.hooks_env = apr_hash_make(result_pool);
- n = svn_config_enumerate_sections2(cfg, parse_hooks_env_section, b,
- scratch_pool);
+ (void)svn_config_enumerate_sections2(cfg, parse_hooks_env_section, b,
+ scratch_pool);
Ugh yuck. We do not use the void-cast style of telling Lint to not cry
about unused return values. Please remove the cast.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1455645 - /subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp
On 12.03.2013 22:02, Bert Huijben wrote: -Original Message- From: br...@apache.org [mailto:br...@apache.org] Sent: dinsdag 12 maart 2013 18:44 To: commits@subversion.apache.org Subject: svn commit: r1455645 - /subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp Author: brane Date: Tue Mar 12 17:43:52 2013 New Revision: 1455645 URL: http://svn.apache.org/r1455645 Log: Working on isue #4326 (update javahl with new 1.8 APIs). * subversion/bindings/javahl/native/SVNClient.cpp (SVNClient::commit): Call svn_client_commit6 (with externals drilldown enabled) instead of svn_client_commit5. Modified: subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp Modified: subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/bindings/javahl /native/SVNClient.cpp?rev=1455645r1=1455644r2=1455645view=diff == --- subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp (original) +++ subversion/trunk/subversion/bindings/javahl/native/SVNClient.cpp Tue Mar 12 17:43:52 2013 @@ -425,8 +425,9 @@ void SVNClient::commit(Targets targets, if (ctx == NULL) return; -SVN_JNI_ERR(svn_client_commit5(targets2, depth, - noUnlock, keepChangelist, TRUE, +SVN_JNI_ERR(svn_client_commit6(targets2, depth, + noUnlock, keepChangelist, + TRUE, TRUE, TRUE, This will probably break Subclipse. The default should be to not go into externals. Clients like subclipse pass a list of targets and depth empty, while this will just commit every external when committing the root of the wc with depth empty. That sounds just wrong. With depth=empty, I'd expect /not/ to recurse into externals, regardless of the value of the include_externals flag. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1438998 - in /subversion/trunk: configure.ac subversion/libsvn_subr/prompt.c
On 27.01.2013 00:56, br...@apache.org wrote: Author: brane Date: Sat Jan 26 23:56:16 2013 New Revision: 1438998 URL: http://svn.apache.org/viewvc?rev=1438998view=rev Log: Fix issue #4280: Prompt the controlling terminal, rather than stdin. This change could potentially break the Windows tests. They pretty much ran for me, at least those I tried, but ... running Windows tests in a VM is painful. So, if anyone finds a bug that may be related to prompting on Windows, please let me know and I'll try to repro and fix. I saw the svn-slik-w2k3-x64-ra fail at about the time I committed, but the build log is garbled and I couldn't make heads or tails of it. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1430975 - /subversion/branches/fsfs-format7/subversion/libsvn_fs_fs/low_level.c
On 09.01.2013 18:54, stef...@apache.org wrote: - if (header-is_delta) + if (header-is_delta == FALSE) Can we please use logical operators to test boolean values, not arithmetic ones? if (!header-is_delta) -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1413451 - /subversion/branches/cache-server/BRANCH-README
On 17.12.2012 11:25, Daniel Shahaf wrote: stef...@apache.org wrote on Mon, Nov 26, 2012 at 00:21:26 -: Author: stefan2 Date: Mon Nov 26 00:21:26 2012 New Revision: 1413451 URL: http://svn.apache.org/viewvc?rev=1413451view=rev Log: On the cache-server branch. * BRANCH-README: add Added: subversion/branches/cache-server/BRANCH-README Added: subversion/branches/cache-server/BRANCH-README URL: http://svn.apache.org/viewvc/subversion/branches/cache-server/BRANCH-README?rev=1413451view=auto == --- subversion/branches/cache-server/BRANCH-README (added) +++ subversion/branches/cache-server/BRANCH-README Mon Nov 26 00:21:26 2012 @@ -0,0 +1,109 @@ +Goal + + +Provide a stand-alone executable that will provide a svn_cache__t +implementation based on a single shared memory. The core data +structure and access logic can be taken from / shared with today's +membuffer cache. The latter shall remain available as it is now. memcached solves the problem you're stating above, and it's an independent third-party project. Your solution is specific to Subversion (it's in libsvn_subr and is not in the public API). If you're solving the same problem memcached does, why does your solution need to be specific to svn? Should it be a standalone tool that Subversion interfaces to as an optional dependency, and any other memcached consumer can switch to too? I don't mean to discourage you from doing this work; I just wonder whether the non-public parts of libsvn_subr is the right place for it to live in. I've been wondering about all this caching, actually. There's memacache, as Daniel mentions, and there's redis, and a bunch of other caching solutions that have different strenghts and weaknesses. Yet here we are, reinventing the wheel (and if I read the mails on the topic correctly, having lots of fun while doing that). It would be much better if fsfs could be configured to use one of several caching servers and then the administrator would worry about the rest. I think it's perfectly fine to require one of them. I realize it's too late to do this for 1.8. But I doubt rolling our own cache server makes any kind of sense. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1371087 - in /subversion/trunk: build.conf
On 09.08.2012 12:10, Bert Huijben wrote: In which cases would it help to detect system library versions? Security updates usually don't update this number (as that breaks on a multiple branch approach) and they are only serviced as part of system updates (and if not there is no way to install a specific version for testing). This will only provide pages of unneeded information in error reports when we have an accurate os version. (win64 +-doubles the number of dlls loaded per process and on win8 many system dlls are split up in smaller components) I'm considering ignoring any library that gets loaded from anywhere in $(WINDIR). But one step at a time. (That'll be a bit more interesting on Unix, but there typically aren't that many shared libs involved there.) The exact version of things like openssl are much more interesting and you don't get these this way.(Reason: not a numeric version scheme and not a separate library if linked stayically) Yes, there are a lot of interesting issues to solve, and I don't pretend that I'll have them all done by 1.8. But I often noticed that version and system info are absent or incomplete in many bug reports and I thought it might help if Subversion provided the required information itself. -- Brane -- Certified Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
Re: svn commit: r1104160 - /subversion/trunk/subversion/libsvn_subr/utf.c
On 17.05.2011 14:16, Hyrum K Wright wrote: apr_atomic_xchgptr() and friends are not available on APR 0.9. (This is causing a buildbot build failure.) Maybe we should just drop support for APR-0.9 finally? I know that we sort of promise to support it, but really, it's been obsolete for years. -- Brane
Re: svn commit: r1064847 - /subversion/trunk/subversion/svnserve/serve.c
On 29.01.2011 21:36, Daniel Shahaf wrote: Hyrum K Wright wrote on Sat, Jan 29, 2011 at 12:03:18 -0600: The protocol document is in error: 'revprops' must always be followed by a list, even if it is the empty list, in which case revprop_items on the server is initialized correctly. If 'revprops' is not followed by a list, the server emits a malformed network data error and closes the network connection post haste. I discovered all this by playing around with a python script to hit an svnserve instance with various combinations of arguments to the log command. Given the above, I think we can just remove the assert, as it won't ever trigger. I see. The server, in spite of the 'protocol' doc, does: SVN_ERR(svn_ra_svn_parse_tuple(params, pool, l(?r)(?r)bb?n?Bwl, paths, which --- because of the last 'l' isn't optional --- throws an error if the tuple is omitted, before the assert() is even reached. We could fix either the documentation or the implementation, but in this case how about tweaking the code to match the docs? --- Wouldn't it be more appropriate to fix the docs to match the code? That's unless that particular difference is a result of a recent change (I can hardly believe it is). -- Brane
