BuildBots

2014-02-14 Thread Ben Reser 
We need our buildbots to work for branches.  I propose the following changes,
in decreasing order of priority.

1) If something like bindings is broken on a build bot for branches then
disable the test on that buildbot.  It is far better to disable bindings tests
than it is to continue to allow the build bot to fail and thus encourage us to
ignore the build bot entirely.

2) We should find a way to keep functioning build slaves for our branches that
support the same tests as we run for trunk.  If that means providing parallel
installations of dependencies on the same machine or using separate machines
then we should do that.

3) The build bot should not use the same slave for builds of branch and trunk
changes.  Right now the waterfall view does not give you a good view of the
state of our branches/trunk.  If I break 1.7.x the bot will show red until the
next build which might be on trunk succeeds.  That's not useful.  I can
understand sometimes running a test on a branch that's not normally tested
(like I did with the 1.7.x-diff-translate branch) and using the 1.7.x slave.
But we really ought to have slaves for each release branch we're using.

Obviously 2 and 3 are longer term propositions.  But #1 is something we should
fix immediately.  To that end I have conducted an audit of what's broken on
which build bots and which release branches.  My findings are below.

1.8.x:
  svn-x64-ubuntu-gcc: works
  svn-x64-centos-gcc: works
  bb-openbsd: doesn't build 1.8.x
  svn-windows-local: JavaHL fails.
  svn-windows-ra: Perl bindings fails.

1.7.x:
  svn-x64-ubuntu-gcc: Ruby bindings fail (build not just tests)
  svn-x64-centos-gcc: works
  bb-openbsd: doesn't build 1.8.x
  svn-windows-local: JavaHL fails.
  svn-windows-ra:  Build fails (can't determine why bot is down right now).

We should disable the swig-rb tests on 1.7.x on svn-x864-ubuntu-gcc since the
problem there is that the version of Ruby on that host is too new for 1.7.x.

Bert said the JavaHL tests on svn-windows-local are known due to some sort of
DLL PATH problem.  We should fix or disable these.

I recall Bert having said in the past that SWIG-PL doesn't build on Windows
properly, we should disable that test for swig-windows-ra.

The build bots are down for Windows right now due to a network issue.  So I
can't run a specific test to determine what's wrong with svn-windows-ra and
1.7.x and the logs for the old builds have been removed already.

We have two ways to handle turning tests off by branch.  First we can pass the
branch into the scripts that it's running for and then turn things off.  The
only problem with this is that svncheck.sh for the *nix buildbots already takes
the list of tests to run.  So we'll need to change the scripts to accept this
in parallel with the master changes to pass it.  We could alternatively detect
the branch from the working copy.  But I'm not sure how easy this will be to do.

Or we could just skip all of the above and get the build bots setup with
separate slaves for each branch and then they can have their own independent
scripts.

I'd start on some of the above steps but I'm also not clear on how these
scripts get updated on the slaves.  Does someone have to do that manually, are
they automatically updated?  If they are manually updated are the current
versions in SVN?  For that matter is there someplace where we document exactly
who is responsible for which slaves?

Re: 1.9.0-alpha1 up for testing/signing

2014-02-14 Thread Ben Reser 
On 2/12/14, 10:30 PM, Ben Reser wrote:
> The 1.9.0-alpha1 release artifacts are now available for testing/signing.
> Please get the tarballs from
>   https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.  There's no particular schedule to this and I
> wouldn't be surprised if we don't find some sort of problems in testing.

So far we have two known issues with this tarball:

svn-populate-node-origins-index doesn't build with Visual Studio 2010, 2012, or
2013 due to the ' in the project's descriptions.  Bert found and fixed this in
http://svn.apache.org/r1568180

Certificate validation failure.  There was a missing initialization that will
make certificates without subjectAltNames randomly fail to validate.
svn.apache.org's certificate just so happens to be such a certificate.  The bug
is such that it will never allow a certificate to be validated that shouldn't
be.  Julian reported this here:
https://mail-archives.apache.org/mod_mbox/subversion-dev/201402.mbox/%3C1392388334.48607.YahooMailNeo%40web87705.mail.ir2.yahoo.com%3E
and I fixed the problem in http://svn.apache.org/r1568349

I wasn't terribly inclined to re-roll 1.9.0-alpha for the first one, but the
second one seems more critical since I'm guessing a lot of people will run into 
it.

I'm not going to immediately run out and produce a new tarball since I suspect
we may find more things, so please continue testing this and let me know if you
find other things.

Re: svn commit: r1567996 - /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c

2014-02-14 Thread Stefan Fuhrmann 
On Fri, Feb 14, 2014 at 1:01 AM, Bert Huijben  wrote:

> Sorry for the big number of small replies...
>
>
>
> And the 'cache->total_reads++;' calls?
>
>
>
> Doesn't that need a similar handling?
>
>
>
> Bert
>
>
>
> *From:* Bert Huijben [mailto:b...@qqmail.nl]
> *Sent:* vrijdag 14 februari 2014 00:58
> *To:* 'Stefan Fuhrmann'; 'Ivan Zhakov'
>
> *Cc:* 'Subversion Development'; 'Stefan Fuhrman'
> *Subject:* RE: svn commit: r1567996 -
> /subversion/trunk/subversion/libsvn_subr/cache-membuffer.c
>
>
>
> [[
>
> Well, you were wrong on your initial point ("missing zero crossing").
>
> And you have been wrong on the "use the atomic functions" bit because
> they don't cover 64 bit integers. The only available option is a critical
> section (svn_mutex__t).
>
> ]]
>
>
>
> The 64 bit integer is for statistics only...
>
>
>
> If you just drop that one (that you only used for debugging your code...
> There is no single read of that variable) the rest can be an atomic
> increment.
>

entry->hit_count is 32 bits and atomic increment would be possible.
cache->hit_count is 64 bits for which we don't have portable atomic
operations.

cache->total_xzy are 64 bits but are for dev statistics only and not an
input
for any logic. When they happen to be updated in a synchronized environment,
that's fine, if not it's o.k., too. There is no need to write 3 or 4 extra
serializable
"increment" functions.

-- Stefan^2.

Re: 1.7.15 up for testing/signing

2014-02-14 Thread Ben Reser 
On 2/14/14, 7:44 AM, Ivan Zhakov wrote:
> On 14 February 2014 17:51, Philip Martin  wrote:
>> Philip Martin  writes:
>>
>>> Ivan Zhakov  writes:
>>>
 I am getting diff_tests#10 failure over all protocols on Windows. All
 other tests pass.
 [[[
 FAIL:  diff_tests.py 10: diff when property was changed but text was not
 ]]]

 The failure is reproducible. Is it known issue? What I should to check?
>>>
>>> The test creates r2 for the file iota that adds svn:eol-style=native.
>>> Then it runs various diffs: -r1:2, -r2:1, etc.  The one that fails is
>>> -rPREV which compares r1 in the repository to r2 in the working copy.
>>> The test expects the diff to show a property change only but a text
>>> change is seen.
>>>
>>> Perhaps the code that converts the working file to repository form is
>>> failing?  The code in question is
>>>
>>>   libsvn_client/diff.c:diff_repos_wc_file_target:2320
>>>
>>> and that code certainly is invoked on my Linux machine.
>>
>> So it looks as if this code is converting the wrong way.  It's supposed
>> to convert from working copy form to repository form but is doing the
>> reverse conversion.  On Linux the conversion is a noop so it works.  At
>> some point we need
>>
>>   if (eol_style == svn_subst_eol_style_native)
>> eol_str = SVN_SUBST_NATIVE_EOL_STR;
>>
>> but I don't know if this should go directly in client/diff.c or whether
>> some other translation function should be used.
>>
> I confirm that all tests pass with proposed patch on Windows over ra_local.

The sad thing here is that the buildbot caught this issue.

Here's the build before the broken change was merged:
https://ci.apache.org/builders/svn-windows-local/builds/651

Here's the one after:
https://ci.apache.org/builders/svn-windows-local/builds/654

The logs are gone so I can't say for sure what the failure is but I'm fairly
comfortable saying the build bot caught this issue.

I just made a test build against the branch I created to fix the problem and it
passes (ignoring the JavaHL issue):
https://ci.apache.org/builders/svn-windows-local/builds/725

We have these build bots but they're next to useless if they have persistent
test failures.  :(

I should have noticed but I've gotten tired of reviewing the buildbot failures
on branches since it's always been spurious.

Re: Bugs in 1.8.5 libsvn_subr which make 32-bit threaded svnserve sometimes hang and eat 100% cpu

2014-02-14 Thread Stefan Fuhrmann 
On Thu, Feb 13, 2014 at 11:07 PM, Peter Samuelson  wrote:

>
> [Stefan Fuhrmann]
> > Fixed in r1567985 using Peter's suggestion.
>
> James, not me!  He's been awesome on the Debian Subversion bits these
> past few months, doing a lot more of the work than I.
>

Just a copy'n'pasto - the commit comment correctly attributes James.

-- Stefan^2.

Re: 1.8.8 up for testing/signing

2014-02-14 Thread Stefan Fuhrmann 
On Fri, Feb 14, 2014 at 12:44 AM, Ben Reser  wrote:

> The 1.8.8 release artifacts are now available for testing/signing.
> Please get the tarballs from
>   https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.  I plan to try and release on February
> 19th so please try and get your votes/signatures in place by February 17th.
>
> Note that autoprop_tests.py is known to have spurious failures from time to
> time when libmagic support is enabled and tests are run in parallel.
>
> Thanks!
>

Summary:

  +1 to release

Platform

  Ubuntu 13.10 x64, Linux 3.11.0-13-generic SMP

  Standard dependencies:
APR 1.4.8
APR-Util 1.5.2
BDB 5.1.6
GCC 4.8.1
httpd 2.4.6
JUnit 4.11
libmagic 5.11
OpenJDK-7 7u25
OpenSSL 1.0.1e
Perl 5.14.2
Python 2.7.5+
Ruby 1.8.7
Swig 2.0.10
zlib 1.2.8

  Manually installed and in-tree dependencies:
SQLite 3.7.15.1
Serf 1.3.2
ctypesgen svn-r151

Verified:

  Tarball contents and signatures

  (fsfs, bdb) x (local, svnserve, neon, serf)
  check-swig-py
  check-swig-pl
  check-swig-rb
  check-javahl
  check-ctypes-python

  ./get-deps.sh

Results:

  All tests passed.

GPG Signatures committed to the dist/dev/subversion repository.

Re: E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

2014-02-14 Thread Philip Martin 
Vincent Lefevre  writes:

> With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error
>
> svn: E175013: Access to '/svn/' forbidden
>
> when I do "svn diff -r118:119 https://host//subdir";, but
> "svn diff -r118:119 https://host//subdir/file"; is OK.
>
> There's no such problem with svn 1.6.12 (r955767) on some other
> Debian machine and svn 1.7.9 (r1462340) on an Ubuntu machine.
>
> I can't find bugs with E175013 on the issue tracker.
>
> Note: I am not the admin of the svn server, so that I don't have
> information about it.

Just to be clear, you mean that 

   svn diff -r118:119 https://host//subdir

returns a diff with 1.6.12 and 1.7.9 but with 1.8.5 it fails with
E175013?

A network trace would help, but I've never had much success getting
wireshark to decode an https conection even when I have access to the
server.  It might be easier to use a debug version of the client to
determine which request is failing.

You may be able to determine which version of Subversion is in use on
the server by examining the HTTP headers with something like "curl -D-".

What sort of change is r119?  Text/properties/adds/deletes/copies?

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: 1.9.0-alpha1 up for testing/signing

2014-02-14 Thread Stefan Fuhrmann 
On Thu, Feb 13, 2014 at 7:30 AM, Ben Reser  wrote:

> The 1.9.0-alpha1 release artifacts are now available for testing/signing.
> Please get the tarballs from
>   https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.  There's no particular schedule to this and
> I
> wouldn't be surprised if we don't find some sort of problems in testing.
>
> Thanks!
>

Summary:

  +1 to release

Platform

  Ubuntu 14.04 x64 (Jan 20 nightly), Linux 3.13.0-5-generic SMP

  Standard dependencies:
APR 1.5.0
APR-Util 1.5.3
BDB 5.3.28
GCC 4.8.2
httpd 2.4.7, worker MPM
JUnit 4.11
libmagic 5.14
OpenJDK-7 7u51
OpenSSL 1.0.1f
Perl 5.18.2
Python 2.7.5+
Ruby 1.9.3
Swig 2.0.11
zlib 1.2.8

  Manually installed and in-tree dependencies:
SQLite 3.8.2
Serf 1.3.3
ctypesgen svn-r151

Verified:

  Tarball contents and signatures

  (fsfs, bdb, fsx) x (local, svnserve, serf)
  check-swig-py
  check-swig-pl
  check-swig-rb
  check-javahl
  check-ctypes-python

  ./get-deps.sh

Results:

  All tests passed.

GPG Signatures committed to the dist/dev/subversion repository.

Re: 1.7.15 up for testing/signing

2014-02-14 Thread Ben Reser 
On 2/14/14, 1:55 AM, Ivan Zhakov wrote:
> I am getting diff_tests#10 failure over all protocols on Windows. All
> other tests pass.
> [[[
> FAIL:  diff_tests.py 10: diff when property was changed but text was not
> ]]]
> 
> Full log attached.
> 
> PLATFORM:
> -
> MS Windows 7 Ultimate (x64)
> Microsoft Visual Studio 2008 Version 9.0.30729.1 SP
> 
> DEPENDENCIES:
> -
> APR: 1.4.8
> APR-Util: 1.5.2
> Apache HTTPD: 2.2.25 with r1497121 and r1497441 reverted.
> zlib: 1.2.3
> OpenSSL: 0.9.8y
> sqlite: 3.7.6.3
> Python: 2.6.6
> serf: 1.1.1
> 
> The failure is reproducible. Is it known issue? What I should to check?

This is a 1.7.15 regression.  We'll fix and roll a 1.7.16.

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Marc Strapetz 
On 14.02.2014 14:18, Marc Strapetz wrote:
>>> Can we think of a better way to design the API so that it returns the 
>>> interesting data without all the redundancy? Basically I think we want to 
>>> describe changes to mergeinfo, rather than raw mergeinfo.
>>
>> Marc,
>>
>> Perhaps a better way to ask the question is: Can I encourage you to write 
>> the API that you want? You already designed a cache for the data. What is 
>> the shape of the data
>>  in your cache, and can the API get the data you want in the form you 
>> want it, directly? We'd be glad to help implement it. Even if you start with 
>> an API which simply iterates over a range of revisions, at least that would 
>> allow for the possibility of improving the efficiency internally at various 
>> layers.
> 
> Looks like our emails have crossed :) I'll dig into the cache code and
> will try to come back with a more detailed API suggestion soon.

I did that now and the storage is quite simple: we have a main file
which contains the diff (added, removed) for every path in every
revision and a revision-based index file with constant record length (to
quickly locate entries in the main file).

This storage allows to efficiently query for the mergeinfo diff for a
path in a certain revision. That's sufficient to build the merge arrows.
Assembling the complete mergeinfo for a certain revision is hard with
this cache, but actually not necessary for our use case.

Hence an API like the following should work well for us:

interface MergeinfoDiffCallback {
  void mergeinfoDiff(int revision,
 Map pathToAddedMergeinfo,
 Map pathToRemovedMergeinfo);
}

void getMergeinfoDiff(String rootPath,
  long fromRev, long toRev,
  MergeinfoDiffCallback callback)
  throws ClientException;

This should give us all mergeinfo which affects any path at or below
rootPath.

When disregarding our particular use case, a more consistent API could be:

void getMergeinfoDiff(Iterable paths,
  long fromRev, long toRev,
  Mergeinfo.Inheritance inherit,
  boolean includeDescendants,   
  MergeinfoDiffCallback callback)
  throws ClientException;

The mergeinfo diff should be received starting at fromRev and ending at
toRev. No callback is expected if there is no mergeinfo diff for a
certain revision. Depending on the server-side storage, we may require
to always have fromRev >= toRev or always fromRev <= toRev. If it
doesn't matter, better have always fromRev <= toRev (for reasons given
below).

Regarding the usage, let's assume always fromRev <= toRev, then we will
invoke

getMergeinfoDiff(cacheRoot, 0, head, callback)

This should start returning mergeinfo diff immediately, starting at
revision 0, so we quickly make at least a bit of progress. Now, if the
cache building process is shutdown and restarted later, it will resume
with the latest known revision:

getMergeinfoDiff(cacheRoot, latestKnownRevision, head, callback)

This procedure will be performed until we have caught up with head.
Note, that the latestKnownRevision is the last revision for which we
have received a callback. Depending on the server-side storage, this may
be different from the current revision which the server is currently
processing at the time the cache building process is shutdown. Hence it
will be important that ranges for which no mergeinfo diff is present
will be processed quickly on the server-side, otherwise we could run
into some kind of endless loop, if the cache building process is
shutdown and resumed frequently.

-Marc

Re: 1.7.15 up for testing/signing

2014-02-14 Thread Ivan Zhakov 
On 14 February 2014 17:51, Philip Martin  wrote:
> Philip Martin  writes:
>
>> Ivan Zhakov  writes:
>>
>>> I am getting diff_tests#10 failure over all protocols on Windows. All
>>> other tests pass.
>>> [[[
>>> FAIL:  diff_tests.py 10: diff when property was changed but text was not
>>> ]]]
>>>
>>> The failure is reproducible. Is it known issue? What I should to check?
>>
>> The test creates r2 for the file iota that adds svn:eol-style=native.
>> Then it runs various diffs: -r1:2, -r2:1, etc.  The one that fails is
>> -rPREV which compares r1 in the repository to r2 in the working copy.
>> The test expects the diff to show a property change only but a text
>> change is seen.
>>
>> Perhaps the code that converts the working file to repository form is
>> failing?  The code in question is
>>
>>   libsvn_client/diff.c:diff_repos_wc_file_target:2320
>>
>> and that code certainly is invoked on my Linux machine.
>
> So it looks as if this code is converting the wrong way.  It's supposed
> to convert from working copy form to repository form but is doing the
> reverse conversion.  On Linux the conversion is a noop so it works.  At
> some point we need
>
>   if (eol_style == svn_subst_eol_style_native)
> eol_str = SVN_SUBST_NATIVE_EOL_STR;
>
> but I don't know if this should go directly in client/diff.c or whether
> some other translation function should be used.
>
I confirm that all tests pass with proposed patch on Windows over ra_local.


-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Julian Foad 
Branko Čibej wrote:

> On 14.02.2014 11:38, Julian Foad wrote:

>> Can we think of a better way to design the API so that it returns the
>> interesting data without all the redundancy? Basically I think we want
>> to describe changes to mergeinfo, rather than raw mergeinfo.
> 
> I wonder, Julian, could something like this be useful for merge in general?
> 
> We know that clients can cache most of the mergeinfo in the
> repository, if they want to; I just don't have any feeling for how
> much sense it would make to maintain such a cache, and if it can be
> made smart enough to speed up merging significantly.


I wasn't sure how much mergeinfo we fetch in a typical merge so I tried some 
merges with current svn branches. They all fetched mergeinfo either two or 
three times, all at the head revision, and the time taken to fetch it was not a 
substantial portion of the overall merge time. So I think the answer is we 
wouldn't currently benefit from this within the scope of one merge. (A 
persistent cache on the client machine is a different matter.)


- Julian

E175013 svn diff failure (access forbidden) with 1.8.5 (regression)

2014-02-14 Thread Vincent Lefevre 
With svn 1.8.5 under GNU/Linux (Debian unstable), I get an error

svn: E175013: Access to '/svn/' forbidden

when I do "svn diff -r118:119 https://host//subdir";, but
"svn diff -r118:119 https://host//subdir/file"; is OK.

There's no such problem with svn 1.6.12 (r955767) on some other
Debian machine and svn 1.7.9 (r1462340) on an Ubuntu machine.

I can't find bugs with E175013 on the issue tracker.

Note: I am not the admin of the svn server, so that I don't have
information about it.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: svn commit: r1565531 - /subversion/trunk/subversion/libsvn_ra_serf/util.c

2014-02-14 Thread Julian Foad 
This commit is causing a change of behaviour for me against the Apache svn 
repo. I think there is an error in this code.

The error I get when trying to run a merge into an svn trunk WC from an svn 
branch is:

$ svn merge --non-interactive ^/subversion/branches/fsfs-ucsnorm/
/home/julianfoad/src/subversion-c/subversion/svn/util.c:548,
/home/julianfoad/src/subversion-c/subversion/libsvn_client/merge.c:11811,
/home/julianfoad/src/subversion-c/subversion/libsvn_client/merge.c:12465,
/home/julianfoad/src/subversion-c/subversion/libsvn_client/ra.c:474,
/home/julianfoad/src/subversion-c/subversion/libsvn_client/ra.c:453,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra/ra_loader.c:485: 
(apr_err=SVN_ERR_RA_CANNOT_CREATE_SESSION)
svn: E170013: Unable to connect to a repository at URL 
'https://svn.apache.org/repos/asf/subversion/trunk'
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/serf.c:593,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/options.c:491,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/util.c:941,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/util.c:915,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/util.c:880,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/util.c:431,
/home/julianfoad/src/subversion-c/subversion/libsvn_ra_serf/util.c:413: 
(apr_err=SVN_ERR_RA_SERF_SSL_CERT_UNTRUSTED)
svn: E230001: Server SSL certificate verification failed: certificate issued 
for a different hostname


> Author: breser

> Date: Fri Feb  7 04:32:50 2014
> New Revision: 1565531
> 
> URL: http://svn.apache.org/r1565531
> Log:
> ra_serf: Do not compare the CommonName of a certificate if there are
> subjectAltName extensions of the DNS type when validating the certificate
> as per RFC 2818.
> 
> * subversion/libsvn_ra_serf/util.c
>   (ssl_server_certificate): add a boolean to know if there were san
>     entries, skip the CN match if there were and move the failure
>     flag outside of the CN match code.
> 
> Modified:
>     subversion/trunk/subversion/libsvn_ra_serf/util.c
> 
> Modified: subversion/trunk/subversion/libsvn_ra_serf/util.c
> URL: 
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_serf/util.c?rev=1565531&r1=1565530&r2=1565531&view=diff
> ==
> --- subversion/trunk/subversion/libsvn_ra_serf/util.c (original)
> +++ subversion/trunk/subversion/libsvn_ra_serf/util.c Fri Feb  7 04:32:50 2014
> @@ -225,6 +225,7 @@ ssl_server_cert(void *baton, int failure
>        ### This should really be handled by serf, which should pass an error
>            for this case, but that has backwards compatibility issues. */
>        apr_array_header_t *san;
> +      svn_boolean_t found_san_entry;
> 
>        serf_cert = serf_ssl_cert_certificate(cert, scratch_pool);
> 
> @@ -232,6 +233,7 @@ ssl_server_cert(void *baton, int failure
>        /* Try to find matching server name via subjectAltName first... */
>        if (san) {

Here, "san" is false (no SubjectAltName found), so found_san_entry remains 
uninitialized...

>            int i;
> +          found_san_entry = san->nelts > 0;
>            for (i = 0; i < san->nelts; i++) {
>                const char *s = APR_ARRAY_IDX(san, i, const char*);
>                if (apr_fnmatch(s, conn->session->session_url.hostname,
> @@ -243,8 +245,11 @@ ssl_server_cert(void *baton, int failure
>            }
>        }
> 
> -      /* Match server certificate CN with the hostname of the server */
> -      if (!found_matching_hostname)
> +      /* Match server certificate CN with the hostname of the server iff
> +       * we didn't find any subjectAltName fields and try to match them.
> +       * Per RFC 2818 they are authoritative if present and CommonName
> +       * should be ignored. */
> +      if (!found_matching_hostname && !found_san_entry)
>          {

... and here we skip this block because found_san_entry is -134885336 i.e. 
"true".

This results in the certificate being considered invalid.

- Julian


>            const char *hostname = NULL;
> 
> @@ -253,13 +258,16 @@ ssl_server_cert(void *baton, int failure
>            if (subject)
>              hostname = svn_hash_gets(subject, "CN");
> 
> -          if (!hostname
> -              || apr_fnmatch(hostname, 
> conn->session->session_url.hostname,
> -                             APR_FNM_PERIOD | APR_FNM_CASE_BLIND) != 
> APR_SUCCESS)
> +          if (hostname
> +              && apr_fnmatch(hostname, 
> conn->session->session_url.hostname,
> +                             APR_FNM_PERIOD | APR_FNM_CASE_BLIND) == 
> APR_SUCCESS)
>            {
> -              svn_failures |= SVN_AUTH_SSL_CNMISMATCH;
> +            found_matching_hostname = 1;
>            }
>        }
> +
> +      if (!found_matching_hostname)
> +        svn_failures |= SVN_AUTH_SSL_CNMISMATCH;
>      }
> 
>    if (!svn_failures)
>

Re: 1.7.15 up for testing/signing

2014-02-14 Thread Philip Martin 
Philip Martin  writes:

> Ivan Zhakov  writes:
>
>> I am getting diff_tests#10 failure over all protocols on Windows. All
>> other tests pass.
>> [[[
>> FAIL:  diff_tests.py 10: diff when property was changed but text was not
>> ]]]
>>
>> The failure is reproducible. Is it known issue? What I should to check?
>
> The test creates r2 for the file iota that adds svn:eol-style=native.
> Then it runs various diffs: -r1:2, -r2:1, etc.  The one that fails is
> -rPREV which compares r1 in the repository to r2 in the working copy.
> The test expects the diff to show a property change only but a text
> change is seen.
>
> Perhaps the code that converts the working file to repository form is
> failing?  The code in question is
>
>   libsvn_client/diff.c:diff_repos_wc_file_target:2320
>
> and that code certainly is invoked on my Linux machine.

So it looks as if this code is converting the wrong way.  It's supposed
to convert from working copy form to repository form but is doing the
reverse conversion.  On Linux the conversion is a noop so it works.  At
some point we need

  if (eol_style == svn_subst_eol_style_native)
eol_str = SVN_SUBST_NATIVE_EOL_STR;

but I don't know if this should go directly in client/diff.c or whether
some other translation function should be used.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Julian Foad 
Marc Strapetz wrote:

>>>  Can we think of a better way to design the API so that it returns the 
>>>  interesting data without all the redundancy? Basically I think we want
>>> to   describe changes to mergeinfo, rather than raw mergeinfo.
>> 
>>  Marc,
>> 
>>  Perhaps a better way to ask the question is: Can I encourage you to write 
>> the API that you want? You already designed a cache for the data. What is 
>> the 
>> shape of the data in your cache, and can the API get the data you want in the
>> form you   want it, directly? We'd be glad to help implement it. Even if you
>> start  with an API which simply iterates over a range of revisions, at least
>> that would  allow for the possibility of improving the efficiency internally
>> at various  layers.
> 
> Looks like our emails have crossed :) I'll dig into the cache code and
> will try to come back with a more detailed API suggestion soon.

Excellent! Thanks.

- Julian

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Marc Strapetz 
>> Can we think of a better way to design the API so that it returns the 
>> interesting data without all the redundancy? Basically I think we want to 
>> describe changes to mergeinfo, rather than raw mergeinfo.
> 
> Marc,
> 
> Perhaps a better way to ask the question is: Can I encourage you to write the 
> API that you want? You already designed a cache for the data. What is the 
> shape of the data
>  in your cache, and can the API get the data you want in the form you 
> want it, directly? We'd be glad to help implement it. Even if you start with 
> an API which simply iterates over a range of revisions, at least that would 
> allow for the possibility of improving the efficiency internally at various 
> layers.

Looks like our emails have crossed :) I'll dig into the cache code and
will try to come back with a more detailed API suggestion soon.

-Marc


On 14.02.2014 14:09, Julian Foad wrote:
> I (Julian Foad) wrote:
> 
>> Can we think of a better way to design the API so that it returns the 
>> interesting data without all the redundancy? Basically I think we want to 
>> describe changes to mergeinfo, rather than raw mergeinfo.
> 
> Marc,
> 
> Perhaps a better way to ask the question is: Can I encourage you to write the 
> API that you want? You already designed a cache for the data. What is the 
> shape of the data
>  in your cache, and can the API get the data you want in the form you 
> want it, directly? We'd be glad to help implement it. Even if you start with 
> an API which simply iterates over a range of revisions, at least that would 
> allow for the possibility of improving the efficiency internally at various 
> layers.
> 
> - Julian
>

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Marc Strapetz 
On 14.02.2014 11:38, Julian Foad wrote:
> Marc Strapetz wrote:
>> For SmartSVN we are optionally displaying merge arrows in the Revision
>> Graph. Here is a sample image, how this looks like:
>>
>> http://imgur.com/MzrLq00
>>
>>> From the JavaHL sources I understand that there is currently only one
>>> method to retrieve server-side mergeinfo and this one works on a single
>>> revision only:
>>
>> Map getMergeinfo(Iterable paths,
>> long revision,
>> Mergeinfo.Inheritance inherit,
>> boolean includeDescendants)
> 
> Right. This is a wrapper around the core library function 
> svn_ra_get_mergeinfo().
> 
>> This makes the Merge Arrow feature practically unusable for larger graphs.
>>
>> To improve performance, in earlier versions we were using a client-side
>> mergeinfo cache (similar as the main log-cache, which TSVN is using as
>> well). However, populating this cache (i.e. querying for mergeinfo for
>> *every* revision of the repository) often resulted in bringing the
>> entire Apache server down, especially if many users were building their
>> log cache at the same time.
>>
>> To address these problems, it would be great to have a more powerful
>> API, which allows either to retrieve all mergeinfo for a *revision
>> range* or for a *set of revisions*.
> 
> The request for a more powerful API certainly makes sense, but what form of 
> API?
> 
> In the Subversion project source code:
> 
>   # How many lines/bytes of mergeinfo in trunk, right now?
>   $ svn pg -R svn:mergeinfo | wc -lc
> 245   24063
> 
>   # How many branches and tags?
>   $ svn ls ^/subversion/tags/ ^/subversion/branches/ | wc -l
>   288
> 
>   # Approx. total lines/bytes mergeinfo per revision?
>   $ echo $((245 * 289)) $((24063 * 289))
>   70805 6954207
> 
> So in each revision  there are roughly 70,000 lines of mergeinfo, occupying 7 
> MB in plain text representation.
> 
> The mergeinfo properties change whenever a merge is done. All other commits 
> leave all the mergeinfo unchanged. So mergeinfo is unchanged in, what, 99% of 
> revisions?
> 
> It doesn't seem logical to simply request all the mergeinfo for each revision 
> in turn, and return it all in raw form.
> 
> Can we think of a better way to design the API so that it returns the 
> interesting data without all the redundancy? Basically I think we want to 
> describe changes to mergeinfo, rather than raw mergeinfo.

True, actually on the client-side we interested in the diff, anyway. So
some kind of callback:

interface MergeInfoDiffCallback {
  void mergeInfoDiff(int revision, Mergeinfo added, Mergeinfo removed);
}

would be convenient. This would work for revision ranges as well as a
set of revisions.

-Marc

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Julian Foad 
I (Julian Foad) wrote:

> Can we think of a better way to design the API so that it returns the 
> interesting data without all the redundancy? Basically I think we want to 
> describe changes to mergeinfo, rather than raw mergeinfo.

Marc,

Perhaps a better way to ask the question is: Can I encourage you to write the 
API that you want? You already designed a cache for the data. What is the shape 
of the data
 in your cache, and can the API get the data you want in the form you 
want it, directly? We'd be glad to help implement it. Even if you start with an 
API which simply iterates over a range of revisions, at least that would allow 
for the possibility of improving the efficiency internally at various layers.

- Julian

Re: 1.7.15 up for testing/signing

2014-02-14 Thread Philip Martin 
Ivan Zhakov  writes:

> I am getting diff_tests#10 failure over all protocols on Windows. All
> other tests pass.
> [[[
> FAIL:  diff_tests.py 10: diff when property was changed but text was not
> ]]]
>
> The failure is reproducible. Is it known issue? What I should to check?

The test creates r2 for the file iota that adds svn:eol-style=native.
Then it runs various diffs: -r1:2, -r2:1, etc.  The one that fails is
-rPREV which compares r1 in the repository to r2 in the working copy.
The test expects the diff to show a property change only but a text
change is seen.

Perhaps the code that converts the working file to repository form is
failing?  The code in question is

  libsvn_client/diff.c:diff_repos_wc_file_target:2320

and that code certainly is invoked on my Linux machine.

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: 1.8.8 up for testing/signing

2014-02-14 Thread Philip Martin 
Summary:

  +1 to release

Platform:

  Linux (Debian/wheezy) 64-bit

Tested:

  (local, svn, svn/sasl, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb)
  swig-pl, swig-py, swig-rb, ctypes-python
  javahl x (fsfs, bdb)

Results:

  All tests successful

Local dependencies:

  apache2-threaded-dev : 2.2.22-13+deb7u1
  libapr1-dev : 1.4.6-3+deb7u1
  libaprutil1-dev : 1.4.1-3
  libdb5.1-dev : 5.1.29-5
  libsasl2-dev : 2.1.25.dfsg1-6+deb7u1
  libsqlite3-dev : 3.7.17-1~bpo70+1
  perl : 5.14.2-21+deb7u1
  python2.7-dev : 2.7.3-6
  ruby1.8-dev : 1.8.7.358-7.1+deb7u1
  openjdk-7-jdk : 7u25-2.3.10-1~deb7u1
  serf : 1.3.x@2243

subversion-1.8.8.tar.bz2
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAABCAAGBQJS/gFOAAoJEHbXiOHtGlmc02oH/RRkG310NDQsKF22BdKZeokN
KZ2zX3FbJc3v+4ExqP0kJ2YtZ03n9V09VG4ymqaEjoZzjHnkeVYRcgqd9jCldU46
C4E0iH5DZOOQ2JtGEhDHzThCnuEt/IzlC04U6ErCCAdyqemDjiSe43MPq0cKpVFJ
qczO2CPE4bPyWcNfYmfp97nNq6d9Je6cesqkWvc3oPaI1C3JgHwu4OFAy7NKYRUD
3P+SyDZMeztzyGcVAwNiWlzFxxOyE7B/cA4MCjt2cHN9Vf9L6nAmNh02EddltdeR
SBNLXnfXmNhDTT21mf4dN693dKy8oCPgBEiCN1Ehj9e4YkX58fith97pxdcxsSM=
=AvzE
-END PGP SIGNATURE-

subversion-1.8.8.tar.gz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAABCAAGBQJS/gFOAAoJEHbXiOHtGlmc5tQH/2rlHGZetVBw/sQttktFtJP0
aM8yPWm8HcnIstIpVYt1OKggUBXJbMn4Gxcff5Z6DBY6IuEgRiotOFwOS2R6JHC2
9ByS9Z4tfX1CF/yueKAT6mtYfKov6WnTgOqZ6OKOZjIKutxQg8pLwT6y3VfHA2Yv
uIW6SyyVQ12VF5HD1sblAdxO0EsCqOCctSRX777EioRxHAGlCKHkBDmYZOgvK1zo
VCVR5B7aplpxhuwEHyvM0d+rGChgcDxjsZgn2invLOQThVFensPxrQcyDJhfQDyY
kQAjCD4VsmQCvcYuVHpmj+XYZIwRsXXKvuCvULSDg3JDJZ5KQDaRQCET0MIQwzM=
=aTFN
-END PGP SIGNATURE-

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Branko Čibej 
On 14.02.2014 11:38, Julian Foad wrote:
> Marc Strapetz wrote:
>> For SmartSVN we are optionally displaying merge arrows in the Revision
>> Graph. Here is a sample image, how this looks like:
>>
>> http://imgur.com/MzrLq00
>>
>>> From the JavaHL sources I understand that there is currently only one
>>> method to retrieve server-side mergeinfo and this one works on a single
>>> revision only:
>> Map getMergeinfo(Iterable paths,
>> long revision,
>> Mergeinfo.Inheritance inherit,
>> boolean includeDescendants)
> Right. This is a wrapper around the core library function 
> svn_ra_get_mergeinfo().
>
>> This makes the Merge Arrow feature practically unusable for larger graphs.
>>
>> To improve performance, in earlier versions we were using a client-side
>> mergeinfo cache (similar as the main log-cache, which TSVN is using as
>> well). However, populating this cache (i.e. querying for mergeinfo for
>> *every* revision of the repository) often resulted in bringing the
>> entire Apache server down, especially if many users were building their
>> log cache at the same time.
>>
>> To address these problems, it would be great to have a more powerful
>> API, which allows either to retrieve all mergeinfo for a *revision
>> range* or for a *set of revisions*.
> The request for a more powerful API certainly makes sense, but what form of 
> API?
>
> In the Subversion project source code:
>
>   # How many lines/bytes of mergeinfo in trunk, right now?
>   $ svn pg -R svn:mergeinfo | wc -lc
> 245   24063
>
>   # How many branches and tags?
>   $ svn ls ^/subversion/tags/ ^/subversion/branches/ | wc -l
>   288
>
>   # Approx. total lines/bytes mergeinfo per revision?
>   $ echo $((245 * 289)) $((24063 * 289))
>   70805 6954207
>
> So in each revision  there are roughly 70,000 lines of mergeinfo, occupying 7 
> MB in plain text representation.
>
> The mergeinfo properties change whenever a merge is done. All other commits 
> leave all the mergeinfo unchanged. So mergeinfo is unchanged in, what, 99% of 
> revisions?
>
> It doesn't seem logical to simply request all the mergeinfo for each revision 
> in turn, and return it all in raw form.
>
> Can we think of a better way to design the API so that it returns the 
> interesting data without all the redundancy? Basically I think we want to 
> describe changes to mergeinfo, rather than raw mergeinfo.

I wonder, Julian, could something like this be useful for improving
merge in general?

We know that clients can cache most of the mergeinfo in the repository,
if they want to; I just don't have any feeling for how much sense it
would make to maintain such a cache, and if it can be made smart enough
to speed up merging significantly.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Julian Foad 
Marc Strapetz wrote:
> For SmartSVN we are optionally displaying merge arrows in the Revision
> Graph. Here is a sample image, how this looks like:
> 
> http://imgur.com/MzrLq00
> 
>> From the JavaHL sources I understand that there is currently only one
>> method to retrieve server-side mergeinfo and this one works on a single
>> revision only:
> 
> Map getMergeinfo(Iterable paths,
>                                     long revision,
>                                     Mergeinfo.Inheritance inherit,
>                                     boolean includeDescendants)

Right. This is a wrapper around the core library function 
svn_ra_get_mergeinfo().

> This makes the Merge Arrow feature practically unusable for larger graphs.
> 
> To improve performance, in earlier versions we were using a client-side
> mergeinfo cache (similar as the main log-cache, which TSVN is using as
> well). However, populating this cache (i.e. querying for mergeinfo for
> *every* revision of the repository) often resulted in bringing the
> entire Apache server down, especially if many users were building their
> log cache at the same time.
> 
> To address these problems, it would be great to have a more powerful
> API, which allows either to retrieve all mergeinfo for a *revision
> range* or for a *set of revisions*.

The request for a more powerful API certainly makes sense, but what form of API?

In the Subversion project source code:

  # How many lines/bytes of mergeinfo in trunk, right now?
  $ svn pg -R svn:mergeinfo | wc -lc
    245   24063

  # How many branches and tags?
  $ svn ls ^/subversion/tags/ ^/subversion/branches/ | wc -l
  288

  # Approx. total lines/bytes mergeinfo per revision?
  $ echo $((245 * 289)) $((24063 * 289))
  70805 6954207

So in each revision  there are roughly 70,000 lines of mergeinfo, occupying 7 
MB in plain text representation.

The mergeinfo properties change whenever a merge is done. All other commits 
leave all the mergeinfo unchanged. So mergeinfo is unchanged in, what, 99% of 
revisions?

It doesn't seem logical to simply request all the mergeinfo for each revision 
in turn, and return it all in raw form.

Can we think of a better way to design the API so that it returns the 
interesting data without all the redundancy? Basically I think we want to 
describe changes to mergeinfo, rather than raw mergeinfo.

- Julian



> Querying a set of revisions would be more flexible and would allow to
> generate merge arrows on the fly. On the other hand, to alleviate the
> server, it's desirable to cache retrieved mergeinfo on the client-side
> anyway, hence a range query would be fine as well.
> 
> -Marc
>

Re: 1.7.15 up for testing/signing

2014-02-14 Thread Ivan Zhakov 
On 12 February 2014 04:05, Ben Reser  wrote:
> On 2/5/14, 4:37 PM, Ben Reser wrote:
>> The 1.7.15 release artifacts are now available for testing/signing.
>> Please get the tarballs from
>>   https://dist.apache.org/repos/dist/dev/subversion
>> and add your signatures there.  I plan to try and release on February
>> 12th so please try and get your votes/signatures in place by February 10th.
>
> This still needs Windows votes.
>
I am getting diff_tests#10 failure over all protocols on Windows. All
other tests pass.
[[[
FAIL:  diff_tests.py 10: diff when property was changed but text was not
]]]

Full log attached.

PLATFORM:
-
MS Windows 7 Ultimate (x64)
Microsoft Visual Studio 2008 Version 9.0.30729.1 SP

DEPENDENCIES:
-
APR: 1.4.8
APR-Util: 1.5.2
Apache HTTPD: 2.2.25 with r1497121 and r1497441 reverted.
zlib: 1.2.3
OpenSSL: 0.9.8y
sqlite: 3.7.6.3
Python: 2.6.6
serf: 1.1.1

The failure is reproducible. Is it known issue? What I should to check?

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
[[[
CMD: svnadmin.exe create svn-test-work\local_tmp\repos --bdb-txn-nosync --fs-type=fsfs

CMD: svn.exe import -m "Log message for revision 1." svn-test-work\local_tmp\greekfiles file:///D:/builder/server/Externals/svn-httpd/subversion/Release/subversion/tests/cmdline/svn-test-work/local_tmp/repos --config-dir D:\builder\server\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom

Adding svn-test-work\local_tmp\greekfiles\A
Adding svn-test-work\local_tmp\greekfiles\A\B
Adding svn-test-work\local_tmp\greekfiles\A\B\lambda
Adding svn-test-work\local_tmp\greekfiles\A\B\E
Adding svn-test-work\local_tmp\greekfiles\A\B\E\alpha
Adding svn-test-work\local_tmp\greekfiles\A\B\E\beta
Adding svn-test-work\local_tmp\greekfiles\A\B\F
Adding svn-test-work\local_tmp\greekfiles\A\mu
Adding svn-test-work\local_tmp\greekfiles\A\C
Adding svn-test-work\local_tmp\greekfiles\A\D
Adding svn-test-work\local_tmp\greekfiles\A\D\gamma
Adding svn-test-work\local_tmp\greekfiles\A\D\G
Adding svn-test-work\local_tmp\greekfiles\A\D\G\pi
Adding svn-test-work\local_tmp\greekfiles\A\D\G\rho
Adding svn-test-work\local_tmp\greekfiles\A\D\G\tau
Adding svn-test-work\local_tmp\greekfiles\A\D\H
Adding svn-test-work\local_tmp\greekfiles\A\D\H\chi
Adding svn-test-work\local_tmp\greekfiles\A\D\H\omega
Adding svn-test-work\local_tmp\greekfiles\A\D\H\psi
Adding svn-test-work\local_tmp\greekfiles\iota

Committed revision 1.
CMD: svnadmin.exe create svn-test-work\repositories\diff_tests-10 --bdb-txn-nosync --fs-type=fsfs

CMD: svnadmin.exe dump svn-test-work\local_tmp\repos | svnadmin.exe load svn-test-work\repositories\diff_tests-10 --ignore-uuid

CMD: svn.exe co file:///D:/builder/server/Externals/svn-httpd/subversion/Release/subversion/tests/cmdline/svn-test-work/repositories/diff_tests-10 svn-test-work\working_copies\diff_tests-10 --config-dir D:\builder\server\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom

Asvn-test-work\working_copies\diff_tests-10\A
Asvn-test-work\working_copies\diff_tests-10\A\B
Asvn-test-work\working_copies\diff_tests-10\A\B\lambda
Asvn-test-work\working_copies\diff_tests-10\A\B\E
Asvn-test-work\working_copies\diff_tests-10\A\B\E\alpha
Asvn-test-work\working_copies\diff_tests-10\A\B\E\beta
Asvn-test-work\working_copies\diff_tests-10\A\B\F
Asvn-test-work\working_copies\diff_tests-10\A\mu
Asvn-test-work\working_copies\diff_tests-10\A\C
Asvn-test-work\working_copies\diff_tests-10\A\D
Asvn-test-work\working_copies\diff_tests-10\A\D\gamma
Asvn-test-work\working_copies\diff_tests-10\A\D\G
Asvn-test-work\working_copies\diff_tests-10\A\D\G\pi
Asvn-test-work\working_copies\diff_tests-10\A\D\G\rho
Asvn-test-work\working_copies\diff_tests-10\A\D\G\tau
Asvn-test-work\working_copies\diff_tests-10\A\D\H
Asvn-test-work\working_copies\diff_tests-10\A\D\H\chi
Asvn-test-work\working_copies\diff_tests-10\A\D\H\omega
Asvn-test-work\working_copies\diff_tests-10\A\D\H\psi
Asvn-test-work\working_copies\diff_tests-10\iota
Checked out revision 1.
CMD: svn.exe propset svn:eol-style native iota --config-dir D:\builder\server\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom

property 'svn:eol-style' set on 'iota'
CMD: svn.exe ci -m empty-msg --config-dir D:\builder\server\Externals\svn-httpd\subversion\Release\subversion\tests\cmdline\svn-test-work\local_tmp\config --password rayjandom --no-auth-cache --username jrandom

Sendingiota

Committed revision 2.
CMD: svn.exe diff -r 1:2 --config-dir D

RFE: API for an efficient retrieval of server-side mergeinfo data

2014-02-14 Thread Marc Strapetz 
For SmartSVN we are optionally displaying merge arrows in the Revision
Graph. Here is a sample image, how this looks like:

http://imgur.com/MzrLq00

>From the JavaHL sources I understand that there is currently only one
method to retrieve server-side mergeinfo and this one works on a single
revision only:

Map getMergeinfo(Iterable paths,
long revision,
Mergeinfo.Inheritance inherit,
boolean includeDescendants)

This makes the Merge Arrow feature practically unusable for larger graphs.

To improve performance, in earlier versions we were using a client-side
mergeinfo cache (similar as the main log-cache, which TSVN is using as
well). However, populating this cache (i.e. querying for mergeinfo for
*every* revision of the repository) often resulted in bringing the
entire Apache server down, especially if many users were building their
log cache at the same time.

To address these problems, it would be great to have a more powerful
API, which allows either to retrieve all mergeinfo for a *revision
range* or for a *set of revisions*.

Querying a set of revisions would be more flexible and would allow to
generate merge arrows on the fly. On the other hand, to alleviate the
server, it's desirable to cache retrieved mergeinfo on the client-side
anyway, hence a range query would be fine as well.

-Marc