Branko Čibej | 27 Jul 10:43 2015

Subversion 1.9.0 up for testing/signing

The 1.9.0 release artefacts are now available for testing/signing.

Please get the tarballs from

and add your signatures there.


Marc Strapetz | 27 Jul 09:17 2015

JavaHL, 1.9: "Bad file descriptor", "Stream doesn't support this capability" errors

One of our 1.9 (early-access) users is reporting problems when 
performing remote commands, for example a copy URL->URL:

org.apache.subversion.javahl.ClientException: Stream doesn't support 
this capability
Bad file descriptor
svn: Polling for available data on filestream failed: Bad file descriptor
	at org.apache.subversion.javahl.SVNClient.copy(Native Method)
	at ...

He hasn't encountered such problems with 1.8 versions.

AFAIU, he is connecting using SSH. Is this an SSH-related problem? Could 
it be related to the underlying SSH client?


Branko Čibej | 27 Jul 09:02 2015

Subversion 1.8.14 up for testing/signing

The 1.8.14 release artefacts are now available for testing/signing.

Please get the tarballs from

and add your signatures there.


Branko Čibej | 27 Jul 07:23 2015

Subversion 1.7.21 up for testing/signing

The 1.7.21 release artefacts are now available for testing/signing.

Please get the tarballs from

and add your signatures there.


Philip Martin | 24 Jul 21:58 2015

Bulk copying revprops

[Arising from some discussion on IRC today.]

I've been considering the problem of a dump/load upgrade for a
repository with a large number of revisions.  To minimise downtime the
initial dump/load would be carried out while the original repository
remains live.  When the load finishes the new repository is already
out-of-date so an incremental dump/load is carried out.  When this
second load finishes the original repository is taken offline and we
want to bring the new repository online as quickly as possible.  A final
incremental dump/load is required but that only involves a small number
of revisions and so is fast.  The remaining problems are locks and

We do not have tools to handle locks so the options are: a) drop all the
locks, or b) copy/move the whole db/locks subdir.  I'm not really
interested in locks at present.

Revprops are more of a problem.  Most revprops are up-to-date but a
small number may be out-of-date.  The problem is we do not know which
revprops are out-of-date.  Is there a reliable and efficient way to
bring the revprops up-to-date?  We could attempt to disable and/or track
revprop changes during the load but this is not reliable.  Post- hooks
are not 100% reliable and revprop changes can bypass the hooks.  We
could attempt to copy/move the whole revprops subdir that is not always
possible if the repository formats are different.

One general solution is to use svnsync to bulk copy the revprops:

  ln -sf /bin/true dst/hooks/pre-revprop-change
  svnsync initialize --allow-non-empty file:///src file:///dst
(Continue reading)

Stefan Hett | 23 Jul 11:57 2015

[PATCH] INSTALL documentation update regarding Perl on Windows


as suggested by danielsh and with the input from Bert on IRC following 
is a suggested patch to correct/update the stated Perl-requirements for 
building on Windows in the install-documentation.

The update applies in principle to 1.7, 1.8, 1.9 and trunk.
The old phrasing incorrectly suggested that Perl was required for 
building SVN with any version of Visual Studio on Windows, while it 
actually is only required when building apr-util with BDB-support on VC6 
(as pointed out by Bert) or when building OpenSSL (with any VS version) 
from source.

The attached patch corrects that statement (patch against current trunk).

Correct statement of when Perl is required on Windows.
(patch suggested by danielsh with input taken from Bert)

     updated/corrected I.C.11 Perl 5.8 or newer (Windows only) (OPTIONAL)

--- INSTALL	(revision 1692358)
(Continue reading)

Stefan Hett | 22 Jul 13:07 2015

detection of moved branches for svn-normalizer tool


I came across a case where svn-normalizer did remove mergeinfo for a 
branch which was still present but got renamed in one revision.
I understand why it behaves the current way, but maybe in favor of the 
improvements done for handling moves it might also be a good idea to 
have svn-normalizer better handle these scenarios?

For a quick demo/test-case showing the underlying issue, I've attached a 
batch-file (for windows) demonstrating the case.

As you see the resulting mergeinfo for FooProject/FooSDK is:

Running svn-normalizer analyse now reports
/SDK/FooSDK as a deleted branch (in r4) and running svn-normalizer 
normalize --remove-obsoletes would then drop this mergeinfo.

Suggested behavior would be that if a branch is renamed and still 
present on trunk, it would not be removed when using svn-normalizer 
normalize --remove-obsoletes.

 <at> echo off

(Continue reading)

Stefan Hett | 21 Jul 12:33 2015

[PATCH] Drop BDB-warning in get-win, if not explicitly building with BDB-support


Drop BDB warnings in gen-make, if building without BDB-support.

* build/generator/
   (__init__): Remove BDB-warning, if optional 'db' library not found in

* build/generator/
   (parse_options): initialize self.bdb_path to None (instead of 
   (_find_bdb): introduce local variable to determine bdb_path taking 
either a
                specified path (via --with-berkeley-db) or attempting the
                default path ('db4-win32')
                Only issue the warning, if failing to locate the BDB 
path AND
                the user having explicitly specified the bdb-path.

Reasoning: BDB support is deprecated and it feels kinda wrong to state 
that a deprecated/optional dependency is missing/skipped, when building 
I kept the old detection behavior (defaulting to db4-win32) however, so 
if a user put the bdb-sources in the default path it would find and use 
them like with the previous versions (not sure whether u want that 
changed or not given the fact that BDB is deprecated).

(Continue reading)

Stefan Hett | 20 Jul 19:08 2015

svn-normalizer tool error E160013


(sending to dev rather than to user since it's still an unreleased tool)

I just tried to do a test-run on another checked-out path from the same 
repository I already ran svn-normalizer on, but get a weird error which 
I don't understand the reason for... Maybe you have an idea?


Scanning working copy E:/[projects]/SDKs ...
     Found mergeinfo on 16 nodes.
     Found 688 branch entries.
     Found 1472 merged revision ranges.

Fetching log for ...svn: 
E160013: '/svn/E
gosoft/!svn/rvr/198196/Foo' path not found


Stefan Hett | 20 Jul 16:20 2015

1.9/trunk build errors when building without OpenSSL


following several hours of investigation and discussion on IRC with 
danielsh, philipm and bert I believe there to be some issue in the build 
generator for Windows.

Running the python command:
python -t vcproj --with-zlib=..\zlib --with-apr=..\apr 
--with-apr-util=..\apr-util --vsnet-version=2010

followed by building (using VS 2010 SP1):
msbuild subversion_vcnet.sln /t:__ALL_TESTS__ /p:Configuration=Release

I get 8 project errors:
- libsvn_ra_dll: LINK : fatal error LNK1181: cannot open input file 
- test_client: LINK : fatal error LNK1181: cannot open input file 
- conflict-data-test: LINK : fatal error LNK1181: cannot open input file 
- some more tests - all with ssleay32.lib missing

ssleay32.lib is an OpenSSL library specified in build.conf in the 
openssl-section alongside libeay32.lib for the "msvc-libs"-option.

Looking at the generated libsvn_ra_dll.vcxproj-file actually shows the 
additional linker dependencies being set to:
(Continue reading)

Stefan Hett | 20 Jul 13:57 2015

[PATCH] Fix build warnings on Windows, if building without OpenSSL


the following patch was suggested by philipm on IRC. I've tested it and 
it resolved the problem I had when building trunk:
"Warning: Using undeclared dependency '$(SVN_OPENSSL_LIBS'."

Following up on r1504208, add openSSL to the list of optional libraries to
properly surpress gen-make warnings on Windows when generating the project
files without openSSL support.
(patch suggested by philipm)

* build/generator/
   (): Add openssl to _optional_libraries array.

I assume the patch should also be considered for backporting to 1.9 
(same issue present there).
I didn't test 1.8 or 1.7 but looking at the code suggests it's not an 
issue there since the patch which promoted openssl to a proper 
dependency library was added post 1.8.

---	(revision 1691913)
+++	(working copy)
(Continue reading)