Ivan Zhakov | 2 Sep 15:01 2015

Strange code in subversion/libsvn_client/blame.c:file_rev_handler()

I've recently encountered strange code in
  /* Prepare the text delta window handler. */
  if (frb->last_filename)
                                     frb->currpool, pool));
    /* Means empty stream below. */
    delta_baton->source_stream = NULL;
  last_stream = svn_stream_disown(delta_baton->source_stream, pool);
  /* Handle all delta - even if it is empty.
     We must do the latter to "merge" blame info from other branches. */
  if (content_delta_handler)
      /* Proper delta - get window handler for applying delta.
         svn_ra_get_file_revs2 will drive the delta editor. */
      svn_txdelta_apply(last_stream, cur_stream, NULL, NULL,
      *content_delta_handler = window_handler;
      *content_delta_baton = delta_baton;
      /* Apply an empty delta, i.e. simply copy the old contents.
(Continue reading)

James McCoy | 2 Sep 06:00 2015

[patch] Fix libsvn_auth_kwallet crash, use-after-free

In Launchpad[0], it was reported that svn will crash when using the
Kwallet integration to store the password during a checkout.  Jens
Jorgensen provided the attached patch, which resolves the issue for me.

At the time, Jens mentioned that subsequent svn commands would still
prompt for the password, but I haven't been able to reproduce that.

[0]: https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/563179


GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jamessan <at> debian.org>
Bert Huijben | 31 Aug 18:59 2015

Download page broken


18:56 < Humbedooh> just a note: your download page is now broken

18:56 < Humbedooh> and we're not gonna fix it for you atm :)

18:56 < <at> Bert> Humbedooh: What part is broken?

18:56 < Humbedooh> it refers to mirrors.cgi

18:56 < Humbedooh> mirrors.cgi is no more

18:57 < Humbedooh> for now, you'll have to do the downloads.cgi like the rest

18:57 < Humbedooh> (this was an emergency fix FWIW)

18:58 < <at> Bert> Humbedooh: Ah.. the us version is broken (the eu version still works)

18:58 < Humbedooh> yes



Anybody interested in fixing this now?


(I’ll see what I can do later, but please fix it if you like)



Stefan Hett | 28 Aug 21:03 2015

E195016 on trying a normal merge / is_reintegrate_like determined correctly?


running the attached test script brings up the following error:
"E195016: Reintegrate can only be used if revisions 2 through 8 were 
previously merged from [branchURL] to the reintegrate source, but this 
is not the case:
         Missing ranges: branches/A:2,5"

The weird thing here (at least weird in my understanding) is that it 
tries to do a reintegration merge even though I'm trying to perform a 
catach-up merge with trunk on the branch.

Looking at merge.c at line 12462 the following if-check determines it's 
a "reintegrate-like" merge and therefore tries to do a reintegration 
merge, instead of a "normal" merge:
if (base_on_source->rev >= base_on_target->rev)

base_on_source->rev = 3
base_on_target->rev = 4

I'm wondering whether this if-check suffices here to determine whether 
it is a reintegration merge or not, given my test-scenario which has 
cherry-picked revisions in both directions (trunk <-> branch).
To me it looks like the check relies on cherry-picking only being 
performed in one or the other direction, because otherwise the 
"youngest-complete-synced-point" couldn't be used to determine the 
direction for reintegration merges...
Or am I missing something?

Sorry if I'm completely off here --- not too familiar with all the 
details of the automerge and it's twisiting my brain trying to 
follow/interpret the design details from code.

Stefan Hett

 <at> echo off
set TESTDIR=C:/[delete]SVN/maxSVN1.7

REM clean-up
rmdir repository /S /Q
rmdir wc /S /Q

REM create repository
mkdir repository
svnadmin create repository

REM create WC
mkdir wc
svn co file:///%TESTDIR%/repository wc
cd wc

REM set-up trunk-branches structure
mkdir trunk
mkdir branches
svn add trunk
svn add branches
svn ci -m "Added branch structure"
REM rev 1

REM testcase
svn cp trunk branches/A
svn ci -m "added branch"
REM rev 2
echo "foo" >trunk\file.txt
svn add trunk\file.txt
svn ci -m "added file.txt"
REM rev 3
echo "foo2" >>trunk\file.txt
svn ci -m "modified file.txt"
REM rev 4
svn merge -r 2:3 file:///%TESTDIR%/repository/trunk branches/A
svn ci -m "merged trunk r3 into branch"
REM rev 5
echo "foo3" >branches\A\file2.txt
svn add branches/A/file2.txt
svn ci -m "added file2.txt"
REM rev 6
echo "foo4" >>trunk\file.txt
svn ci -m "modified file.txt again"
REM rev 7
svn up
svn merge -r 5:6 file:///%TESTDIR%/repository/branches/A trunk
svn ci -m "merged branch r6 into trunk"
REM rev 8
svn merge file:///%TESTDIR%/repository/trunk branches/A

cd ..

REM svn: E195016: Reintegrate can only be used if revisions 2 through 8 were previously merged from
[branchURL] to the reintegrate source, but this is not the case:
REM trunk
REM Missing ranges: branches/A:2,5
Andreas Stieger | 27 Aug 22:02 2015

bash completion for arguments to svn info --show-item


follow up to

* tools/client-side/bash_completion
  (_svn): Complete arguments to svn info --show-item

Marc Strapetz | 27 Aug 17:44 2015

JavaHL: strange/impossible IOException

We have just received following bug report which shows an impossible 
stack trace:

> java.io.IOException: No space left on device
> 	at java.io.FileOutputStream.writeBytes(Native Method)
> 	at java.io.FileOutputStream.write(Unknown Source)
> 	at org.apache.subversion.javahl.remote.RemoteSession.nativeGetFile(Native Method)
> 	at org.apache.subversion.javahl.remote.RemoteSession.getFile(RemoteSession.java:167)

I'm considering it as "impossible", because RemoteSession.nativeGetFile 
only throws a ClientException and no IOException. I guess the only 
possible way to throw a checked Exception which is not declared is from 
native code. Now I'm wondering whether this might be related to the 
Exception wrapping/unwrapping problem which Bert has addressed in 
r1664939 (and following)? Btw, these kinds of stack traces have also 
been reported for the javahl-1.8-extensions branch.


Branko Čibej | 27 Aug 16:52 2015

Subversion 1.9.1 up for testing/signing

The 1.9.1 release artefacts are now available for testing/signing.
The planned release date is Wednesday, 2nd September.

Please get the tarballs from


and add your signatures there.


Jörg Rebenstorf | 26 Aug 13:09 2015

subversion issue 2516

I have a suggestion for a solution of issue 2516 of the subversion issue
tracker. Please comment on this and forward my suggestion to issue 2516
of the issue tracker database if feasible.

I suggest we shall have a new access method to solve this usability
problem, something that does not need existing svn repositories to be
changed and something that is not incompatible with existing svn

The new access option should update the working copy of the primary
target "PATH..." and its externals to a certain inter-repository
consistent state, that is, to update the primary target and all of its
externals content to their appropriate version at a certain point in
The new access method shall be an additional command-line option, for
example "--sync-externals", for the svn client tool's update command

svn update -r212 --sync-externals [PATH...]
svn update -r{2015-08-26} --sync-externals [PATH...]

What this new option shall do is, that if an externals definition, that
is involved in the update procedure as-is, does not specify a revision
(or date) information then it shall use the corresponding revision
number (or date) for updating the external so that the external
repository matches the revision of the primary target in time, that is,
the user will update the working copy to that specific state of the
content what the involved repositories had stored at that point in time
(i.e. their former HEAD revision of the past). This should work for
linking via svn:externals inside the same repository as well as for
externals to other repositories.

I believe many users already have linked via svn:externals without a
given revision number for that link definition. So currently these
definitions can only be used to update to the *current* HEAD of these
externals (as defined). But I believe many also want to use this setup
to update via the externals to the HEAD of these linked repositories as
they were at that certain point in time in the past, when updating the
working copy of the repository, that includes the externals definitions,
to a specific revision.

So when an svn:externals definition states a specific revision number to
use, than this specified revision number shall still be used no matter
if --sync-externals is used or not, but else the new option should make
a difference.

I think my solution is better than the "-rPARENT" enhancement (suggested
by Karl Fogel) and similar solutions because needing to specify
something like "-rPARENT" in the externals definition implies to change
existing repositories backward in time to use that feature for existing
ones as these definitions are part of the repository in our situation.

Best regards,
Jörg Rebenstorf

C. Michael Pilato | 25 Aug 17:06 2015

New 'svn cp --pin-externals' feature compat question.

I was reading up on the new 'svn cp --pin-externals' feature in the 1.9 release notes.  Great addition, by the way, and one that I hope to use myself with ViewVC's release tags.

One question came to mind, though.  The use of the feature appears to result in pegged externals definitions (as in, <at> -bearing URLs).  That's great and obviously the correct approach.  But if I recall correctly, this means that use of the feature will cause the copy's externals to be written in a way that older (pre-1.5) clients do not understand.

Is that correct?  If so, I think that's a fine limitation to have -- no complaints at all here.  But perhaps this merits a mention in the Compatibility section of the release notes?

-- Mike
Brett Randall | 24 Aug 02:42 2015

[PATCH 1/2] Fixed check-mime-type.pl so that it also works for svnlook versions from 1.7.8 (r1416637).

In r1416637, svnlook proplist --verbose output changed from propname : propval format, to an indented output:

Properties on ...

This change makes check-mime-type aware of both the pre 1.7.8 and 1.7.8+ formats.

Signed-off-by: Brett Randall <javabrett <at> gmail.com>
 contrib/hook-scripts/check-mime-type.pl | 35 +++++++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/contrib/hook-scripts/check-mime-type.pl b/contrib/hook-scripts/check-mime-type.pl
index 9ac7e8d..8789aaa 100755
--- a/contrib/hook-scripts/check-mime-type.pl
+++ b/contrib/hook-scripts/check-mime-type.pl
 <at>  <at>  -119,17 +119,40  <at>  <at>  foreach my $path (  <at> files_added )

 		# Parse the complete list of property values of the file $path to extract
 		# the mime-type and eol-style
-		foreach my $prop (&read_from_process($svnlook, 'proplist', $repos, '-t',
-		                  $txn, '--verbose', '--', $path))
+		my  <at> output = &read_from_process($svnlook, 'proplist', $repos, '-t',
+					$txn, '--verbose', '--', $path);
+		my $output_line = 0;
+		foreach my $prop ( <at> output)
-				if ($prop =~ /^\s*svn:mime-type : (\S+)/)
+				if ($prop =~ /^\s*svn:mime-type( : (\S+))?/)
-						$mime_type = $1;
+						$mime_type = $2;
+						# 1.7.8 (r1416637) onwards changed the format of svnloop proplist --verbose
+						# from propname : propvalue format, to values in an indent list on following lines
+						if (not $mime_type)
+							{
+								my $next_line_pval_indented = $output[$output_line + 1];
+								if ($next_line_pval_indented =~ /^\s{4}(.*)/)
+									{
+										$mime_type = $1;
+									}
+							}
-				elsif ($prop =~ /^\s*svn:eol-style : (\S+)/)
+				elsif ($prop =~ /^\s*svn:eol-style( : (\S+))?/)
-						$eol_style = $1;
+						$eol_style = $2;
+						if (not $eol_style)
+							{
+								my $next_line_pval_indented = $output[$output_line + 1];
+								if ($next_line_pval_indented =~ /^\s{4}(.*)/)
+									{
+										$eol_style = $1;
+									}
+							}
+				$output_line++;

 		# Detect error conditions and add them to  <at> errors


Stefan Fuhrmann | 23 Aug 23:27 2015

Issue #4588, part 3: Build issues on CentOS

The latest relevant section taken from that issue:

Secondly, I would like to install Subversion 1.9 to try it out, but I'm running CentOS 6.4 and I just can't get Subversion 1.9 to build. As I mentioned below, I have to download the latest Serf version, which doesn't come with CentOS 6.4. And building serf doesn't work. I try just "scons", but then "scons check" fails with things like "test/test_buckets.c:1559: warning: integer overflow in expression". Plus scons wants "APR", "APU", "OPENSSL", and "PREFIX" parameters (according to the README.TXT). I'm sure my APR path isn't correct---on this server I used the Apache from yum and don't know where my APR libraries are. I don't even know what APU is. So it seems highly unlikely for me to get HTTP(S) support on Subversion 1.9. The Subversion build process is and has always been an utterly brittle mess. See Bug 4589, which indicates my frustration.

Is there anything we can reasonably do about it?

-- Stefan^2.