Apache Subversion 1.10 Release Notes
Apache Subversion 1.10 Release Notes

 











What's New in Apache Subversion 1.10
  ¶



  Improved path-based authorization
  New interactive conflict resolver
  LZ4 Compression
  Shelving (experimental)
  Many enhancements and bug fixes
  Known issues in the release
  


Apache Subversion 1.10 is a superset of all previous Subversion
releases, and is as of the time of its release considered the current
"best" release.  Any feature or bugfix in 1.0.x through 1.9.x is also
in 1.10, but 1.10 contains features and bugfixes not present in any
earlier release.  The new features will eventually be documented in a
1.10 version of the free Subversion book
(svnbook.red-bean.com).

This page describes only major changes.  For a complete list of
changes, see the 1.10 section of the CHANGES
file.

  


Compatibility Concerns
  ¶


Older clients and servers interoperate transparently with 1.10
servers and clients.  However, some of the new 1.10 features may not be
available unless both client and server are the latest version.  There are
also cases where a new feature will work but will run less efficiently if
the client is new and the server old.

There is no need to dump and reload your repositories. 
Subversion 1.10 servers can read and write to repositories created by
earlier versions.  To upgrade an existing server installation, just install the
newest libraries and binaries on top of the older ones.

Subversion 1.10 maintains API/ABI compatibility with earlier
releases, by only adding new functions, never removing old ones.  A
program written to any previous 1.x API can both compile
and run using 1.10 libraries.  However, a program written for 1.10
cannot necessarily compile or run against older libraries.

There may be limited cases where the behavior of old APIs has been
slightly modified from previous releases.  These are cases where edge cases
of the functionality has been deemed buggy, and therefore improved or removed.
Please consult the
API errata for more detailed information on what these APIs are
and what impact these changes may have.


New Feature Compatibility Table
  ¶


  
    New Feature
    Minimum Client1
    Minimum Server
    Minimum Repository
    Notes
  
    
      Improved path-based authorization
    
    any
    1.10
    any
    Existing authz configurations may need to be adjusted.
  
    
      New interactive conflict resolver
    
    1.10
    any
    any
    Use SVN 1.8 and above clients only for best results.
  
    
      LZ4 compression over the wire in http:// and svn:// connections
    
    1.10
    1.10
    any
    
  
    
      LZ4 compression in the backend storage
    
    any
    1.10
    1.10
    FSFS only
  
    1Reminder: when using the file://
    repository access method, the Subversion program is both the client
    and the server.


  


Upgrading the Working Copy
  ¶


Subversion 1.10 uses the same working copy format as Subversion 1.8 and 1.9.

Before using Subversion 1.10 with an existing Subversion 1.7 or older
working copy, users will be required to run the svn upgrade command
to upgrade working copy metadata to the new format. This command may take a
while in some cases, and for some users, it may be more practical to simply
checkout a new working copy.

Note: Subversion 1.10 cannot upgrade working copies that
a 1.6 client would have refused to operate upon before an svn cleanup
was run (with a 1.6 client).  In other words, before upgrading to 1.8 or newer,
a 1.6
or older client must be used to run svn cleanup on all 1.6 or older
working copies that require cleanup.  Likewise, Subversion 1.10 cannot upgrade
corrupt working copies. Unfixable problems can arise from missing or corrupt
meta-data inside .svn directories.  Such damage to the working copy
is permanent, and cannot be fixed even if svn cleanup is run prior
to the upgrade.

If your working copy does not upgrade cleanly, please check out a new one.


  




Miscellaneous Compatibility Notes
  ¶


There are some additional specific areas where changes made in this
release might necessitate further adjustment by administrators or
users.  We'll cover those in this section.


This release is numbered 1.10
  ¶


Since "1.10.0" is smaller than "1.9.0" when considered as ASCII strings,
scripts that compare Subversion versions as strings may fail to correctly
determine which of "1.10.0" and "1.9.0" is the more recent one.  Such
scripts should be changed to compare Subversion version numbers correctly:
as tuples of integers, with an optional suffix for development or pre-release
versions.  See
the Subversion release numbering documentation
for details.  (Programs written against the C API or the various bindings
should refer to the 

svn_version_* interfaces.)

  


New path-based authorization compatibility
  ¶


The improved path-based authorization
  changes the behaviour of some existing authz files.

The 1.9 and earlier implementations allowed multiple rules for the
same path:

  [/some/path]
  userA = r
  [/some/path]
  userB = rw


In 1.9 this would define access for both userA
and userB, in 1.10 this raises an error and no access is
possible.

The 1.9 and earlier implementations allowed multiple entries
matching the same name, alias or group and the last match applied:

  [/some/path]
  user = rw
  user = r
  &alias = rw
  &alias = r
  @group = rw
  @group = r


In 1.9 the final, read-only, match
for user, &alias and @group would be
selected while 1.10 combines all the lines to give read-write access.
The 1.10 implementation may change in future releases, perhaps to
make this case an error.

A fix for Issue #4762 may change the way path-based authorization rules are applied
in some circumstances. See r1882326.

Background: Subversion 1.10 introduced a new implementation of path-based
authorization (authz) to deliver wildcard support and improved performance
over that of Subversion 1.9 and earlier. From Subversion 1.10 through 1.14.0,
the new implementation did not correctly combine global rules with repository
rules: if a global rule and a per-repository rule were both present for a
path, the global rule would be ignored and the per-repository rule would
apply by itself. As a result, from Subversion 1.10 through 1.14.0, it was not
possible to override per-path access rules for specific users (or groups) at
the global level. Administrators whose authz rules rely on this incorrect
behavior may need to adjust their rules accordingly.


This issue is fixed in 1.14.1, making it possible once again to
override per-path access rules for specific users (and groups) at the global level.
Such global rules are overridden by repository-specific rules only if both the
user and the path match the repository-specific rule.

As an example, consider the following rule set:

[groups]
company = developer1, developer2, developer3
customer = customer1, customer2

# company can read-write on everything
[/]
@company = rw

[project1:/]
@customer = r



Does developer1 have rw access to "/trunk" in project1?



Subversion servers running 1.10.0 up to 1.10.6 or 1.14.0, without the fix for
issue #4762, will only apply the repository-specific part of the rule set:
[project1:/]
@customer = r


The answer in this case is that developer1 has no access at all because the
global rule which grants rw access to the @company group is ignored.



Subversion servers running 1.14.1 or later match the behaviour of
Subversion 1.9, meaning they will apply both the global and the repository-specific
part of the rule set:
# company can read-write on everything
[/]
@company = rw

[project1:/]
@customer = r


The answer in this case is that developer1 has rw access
to any path in project1.
Global rules are overridden by repository-specific rules only if both the
user (developer1) and the path ("/", including child paths
for which no specific rules exist) match the repository-specific rule.
While the repository-specific rule matches "/trunk" it does not
match developer1, and hence the global rule will be used.



  


svnadmin subcommands print locked paths differently
  ¶




The
svnadmin lock,
svnadmin unlock, and
svnadmin rmlocks
subcommands print the locked path differently.

In 1.9 and earlier, the path would be printed out in exactly the form it was input.
In 1.10, the path is printed in "canonical" form:
with dot components (foo/./bar) elided and multiple slashes (foo//bar) compressed to one.
The path also starts with a slash in the output,
regardless of whether a leading slash was present in the input.

Example:

$ svnadmin-1.9 lock r //iota jrandom logmsg opaquelocktoken:42
'//iota' locked by user 'jrandom'.
$ svnadmin-1.9 unlock r //iota jrandom opaquelocktoken:42
'//iota' unlocked by user 'jrandom'.


$ svnadmin-1.10 lock r //iota jrandom logmsg opaquelocktoken:42
'/iota' locked by user 'jrandom'.
$ svnadmin-1.10 unlock r //iota jrandom opaquelocktoken:42
'/iota' unlocked by user 'jrandom'.
$


Only the output is changed.
The set of valid inputs and the behaviour of svnadmin on them are unchanged.
svnadmin continues to accept paths either with or without multiple slashes,
dot components, and so on as command-line arguments.

  


svnserve honours use-sasl = true when built without SASL
  ¶




The behaviour of svnserve when built without support for Cyrus SASL
transport has changed.

In Subversion 1.9 and earlier, svnserve, when built without SASL support,
  would ignore the svnserve.conf use-sasl setting;
In Subversion 1.10, svnserve, when built without SASL support,
  errors out if use-sasl is set to true.

svnserve's behaviour is otherwise unchanged.
In particular, the behaviour of builds with SASL support is unchanged.

An API erratum is available.

  


New CA keys may be required
  ¶



Some binary distributions of this new Subversion version
may link to a newer OpenSSL version than previous distributions.
This may lead to different behavior.



Especially, some distributions may link this Subversion release to OpenSSL 1.1 instead of OpenSSL 1.0.
OpenSSL 1.1 does not allow md5 hashes for CA keys anymore.
When using client certificates signed by such a CA,
the new Subversion client may fail with An error occurred during SSL communication.
You can analyze the underlying cause by first converting the client certificate from p12 to pem by
openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem

and then testing the SSL connection by
openssl s_client -connect example.com:443 -servername example.com -cert cert.pem

If this test connection fails with ca md too weak
then creating new CA keys using sha256 instead of md5
and corresponding new client certificates should solve the problem.



See also When performing Subversion operations
over SSL, I get the error An error occurred during SSL communication


  

  

  


New Features
  ¶



Improved path-based authorization 
  ¶

 Subversion 1.10 provides a new implementation of path-based authorization
    with improved performance and wildcard support. There are some
    compatibility issues.

Existing authz rules come in two flavours, repository-specific and global:
      [repos:/path]
   [/path]
   In these rules, /path is always matched literally.

The new authz rule parser supports two new forms for rules which may contain
   wildcards in the path element:
      [:glob:repos:/path]
   [:glob:/path]

The following wildcard syntax elements are supported in glob rules:

* matches a single (exactly one), arbitrary path segment
** matches an arbitrary number of path segments, separated by a forward slash: /
Classic wildcard patterns such as *foo*.bar work as expected, including escaping of special
    characters with a backslash: \



All wildcards apply to full path segments only, i.e. * never matches /, except for the
case where /**/ matches zero or more path segments. For example, /*/**/* will match any path
which contains at least 2 segments and is equivalent to /**/*/* as well as /*/*/**. 

Because a glob rule is not required to contain wildcards in the path, two sections
   with different names may apply to the same path. For example, the following two
   rules are identical:
      [/path/without/wildcards]
   [:glob:/path/without/wildcards]
   The new authz rule parser detects and rejects such collisions.

The old authz parser, in Subversion 1.9 and earlier, allowed syntactic
   entries which grant write-only access. For example:
      [/]
   * = w
  The new parser flags such entries as invalid.
  Neither the old nor the new authz implementation support write-only access.

  


New interactive conflict resolver
  ¶


Subversion 1.10 provides much better interactive resolution of tree conflicts
   than previous releases.
   Interactive conflict resolution has been completely redesigned and rewritten.
   This new conflict resolver supersedes the first implementation introduced
   in Subversion 1.5.

The new conflict resolver searches repository history for structural changes
   (additions, deletions, copies, and moves) which conflict with local changes
   in the working copy and cause tree conflicts. Tree conflicts are now described
   in detail, including revision numbers and names of authors of conflicting changes.
   In previous versions of Subversion, the task of finding such information was
   left to the user. Automating this task is a huge usability improvement.

The new conflict resolver is able to detect moves and renames in repository
   history, and take them into account while modifying the local working copy.
   This makes seamless merging between branches possible even if one or both
   branches rename files or directories. For best results, all SVN clients
   committing to the repository should be at version 1.8 or higher.

The new conflict resolver will avoid asking users about resolution options
   whenever there is a only one reasonable course of action. For example, if
   a file was moved to another location in the repository, the conflict
   resolver will attempt to resolve the tree conflict on behalf of the user
   by performing the same move locally if necessary. This allows users to focus
   their attention on conflicts which cannot be resolved automatically.

Because detection of moves and renames involves heuristics, detection
   is not perfect and won't work in all conceivable cases. For a detailed
   description of how incoming moves and renames are detected, see 
   How Subversion's conflict resolver handles incoming moves.
   
 
The conflict resolver user interface remains largely unchanged. Like in
   previous releases, the resolver will be started automatically if an update,
   merge, or switch operation ends with unresolved conflicts. It can also be
   started on demand by running the svn resolve command. For more
   information, run svn help resolve after installing Subversion 1.10.

In some situations, resolving one tree conflict will cause new other tree conflicts
   to appear. The svn resolve command will keep iterating over such conflicts
   until none are left, or until the user decides to quit the operation.

The new conflict resolver can be driven interactively with
   svn resolve, from Subversion's client API (in C and other language
   bindings), or with the non-interactive svnconflict
   tool which is intended for use in shell scripts.

The new conflict resolver offers a variety of automated tree conflict resolution
   options which users can choose from. Not all kinds of tree conflicts can yet be
   described and resolved. The options available in Subversion 1.10.0 are listed in
   the table below. In this table, the items on the incoming and local side are either
   both files or both directories. Most cases where files clash with directories are
   not handled yet.

Future releases of Subversion will continue to provide enhancements for the new
   conflict resolver. We expect to add coverage of additional conflict cases and add
   additional resolution options even in patch releases (i.e. in 1.10.1, 1.10.2, etc.).


  
    local change
    incoming change
    operation
    resolution options
  
  
    
      edit file
      any change inside a directory
    
    
      delete file / directory
    
    update, switch, merge
    
      ignore deletion
      accept deletion
    
  
  
    
      move file / directory
    
    update, switch, merge
    
      move and merge
          (applies the same move locally and merges items)
    
  
  
    
      add item
    
    
      add item
    
    update, switch
    
      ignore incoming addition
          (discards the incoming change)
      merge incoming and local item
    
  
  
    merge
    
    
      ignore incoming addition
          (discards the incoming change)
      merge incoming and local item
          (item's log history will trace back on local branch)
      replace local item with incoming item, then merge them
          (item's log history will trace back to other branch)
    
  
  
    
      move item
    
    
      edit file
      any change inside directory
    
    update, switch
    
      apply change to move destination
      break move and update any moved away children
          (updates items moved outside of the moved directory)
    
  
  
    merge
    
      apply change to move destination
    
  
  
    
      delete item
    
    
      edit file
      any change inside directory
    
    update, switch, merge
    
      keep working copy state (deleted file / directory),
      discarding incoming changes
    
  


  


LZ4 compression
  ¶


Subversion 1.10 adds support for LZ4
compression as an alternative to the zlib
compression that has been used in the previous versions.  LZ4 offers fast
compression and decompression while still maintaining a decent compression
ratio.  Using LZ4 compression can significantly improve performance of most
of the Subversion read and write operations, especially for repositories
containing large files.


LZ4 compression is now used by default for the on-disk data in repositories
with filesystem format 8.  Also, Subversion 1.10 adds support for automatic
negotiation and use of LZ4 compression over the wire for http:// and svn://
connections when it is supported by both endpoints.


Filesystem format bump
  ¶


The default filesystem format is now version 8, introduced in 1.10.
The format
bump is required to allow using LZ4 compression for the data that is stored
on the disk.  (The
svnadmin info
command displays the filesystem
format number of a repository.)

Existing repositories can be upgraded to the new format with the
svnadmin upgrade command.

  


Configuring the repository to use LZ4 compression
  ¶


Repositories created with Subversion 1.10 and existing repositories
upgraded to format 8 will by default compress new data using LZ4.
The compression algorithm can also be configured explicitly by setting the
compression = none | lz4 | zlib | zlib-1 ... zlib-9 option in the
fsfs.conf repository configuration file.

Existing repositories with the configured compression-level
option in the fsfs.conf file will continue to use zlib compression.
In order to start using LZ4 compression for such repositories, consider
setting the compression = lz4 option in the fsfs.conf
file.

In order to speed up read and write operations for existing repositories,
consider recompressing the data stored in them with LZ4.  This can be achieved
by performing a full
dump/load
cycle into a new format 8 repository created with Subversion 1.10.

  


LZ4 compression over the wire in http:// and svn:// connections
  ¶


Deltas transferred between Subversion 1.10 clients and servers may be
compressed with LZ4.  The actual choice of the compression algorithm depends
on the used protocol, environment and its configuration — see below.

For the http:// protocol, use of LZ4 compression depends on the values
of the server-side SVNCompressionLevel directive, client-side
http-compression configuration option and on the network
capabilities.  LZ4 compression generally offers much faster compression
and decompression speeds, but slightly worse compression ratio than zlib.
By default, it is only preferred for low latency networks where the
overhead associated with transferring the additional amount of data is
assumed to be negligible.


  
    On the server-side, SVNCompressionLevel 0
    can be used to disable compression altogether.  The special value of
    SVNCompressionLevel 1 forces the use of LZ4 compression for
    clients that support it. All other values result in preferring zlib
    compression with the respective compression level.  Note that the
    negotiated algorithm is still subject to the client's configuration.
    For example, even if the server is configured to prefer zlib compression
    over LZ4, a client may still negotiate the use of LZ4 compression when
    its http-compression option is set to auto.
  
  
    On the client-side, setting http-compression to
    either yes or no will enable or disable compression
    that is then negotiated based on the server's configuration.
    The default value of auto will result in preferring LZ4
    compression for low latency networks and zlib compression otherwise.
  


Below is the table explaining the used compression algorithm in each
combination of the client- and server-side configuration options:


  
    
    1.10 Serverwith SVNCompressionLevel:
    1.9 and older Serverwith SVNCompressionLevel:
  
  
    Subversion Client
    0
    1
    2-9 (default: 5)*
    0
    1-9 (default: 5)*
  
  
    1.10, http-compression: auto*, low latency
    None
    LZ4
    LZ4
    None
    zlib
  
  
    1.10, http-compression: auto*, high latency
    None
    LZ4
    zlib
    None
    zlib
  
  
    1.10, http-compression: yes
    None
    LZ4
    zlib
    None
    zlib
  
  
    1.10, http-compression: no
    None
    None
    None
    None
    None
  
  
    1.9 and older, http-compression: yes*
    None
    zlib
    zlib
    None
    zlib
  
  
    1.9 and older, http-compression: no
    None
    None
    None
    None
    None
  


* Default configurations

For the svn:// protocol, use of LZ4 compression depends on the value
of the server-side -c/--compression option.  A value of 0
disables compression entirely; any other value causes lz4 or zlib compression
to be used.  At this time, lz4 is always used in preference to zlib when both
are supported by the remote end.

  

  


Shelving (experimental)
  ¶


Shelving (issue
#3625) is the ability to put aside an uncommitted change in the WC, as
if putting it on a shelf, in order to work on something else, and later
bring the change back in to the WC. It is very similar to saving a patch
file created by svn diff and later applying it with svn
patch.

The following svn commands are new; see their help for details.
svn shelve [--keep-local] NAME [PATH...]
    svn unshelve [--keep-shelved] [NAME]
    svn shelve --delete NAME
    svn shelves (or svn shelve --list)


WARNING: The shelving feature is
  designated "EXPERIMENTAL" in 1.10. It is being released in an early form
  while development continues. It is expected to change significantly during
  and after the 1.10.x series. There is no promise of backward compatibility
  while it remains experimental.

  

  


Enhancements and Bugfixes
  ¶





Command-line client improvements (client)
  ¶



svn log --search  improvements
  ¶


svn log --search is now case-insensitive and ignores diacriticals
when matching words. This makes it easier to match paths and log messages
which happen to contain upper-case and non-English characters.

 


New svn ls --search option
  ¶


You may now specify one or more glob patterns in a svn ls
request.  Note that most shells require globs to be put in quotation
marks to be passed as-is to SVN.  Example:
      svn ls svn://server/repo --recursive --search "readme*"
Against a Subversion 1.10 server, this command will be executed
as a single, efficient server-side query.


  


svnbench improvements
  ¶


svnbench now displays its wall-clock run time and the total
number of bytes transferred across the network. The --with-no-revprops
option which did not actually work in Subversion 1.9 has been fixed.

 


New option --accept recommended
  ¶


The new option --accept recommended will automatically
resolve tree conflicts for which a recommended resolution option is
available. Any other conflicts will be postponed.

Note that --accept recommended is now the default behaviour
if the --non-interactive option is used. In previous releases,
the --non-interactive option implied --accept postpone
by default instead.

 

 


Server-side improvements
  ¶



Revprop caching enabled
  ¶


Revprop caching was an optional FSFS feature in previous releases
but is now always enabled.  In previous releases revprop caching could
be enabled for mod_dav_svn via the SVNCacheRevprops
directive, and for svnserve by the --cache-revprops command
line option.  That directive and command line option are now silently
ignored and revprop caching is enabled for all FSFS access.

 


New --no-flush-to-disk option for svnadmin load
  ¶


A new --no-flush-to-disk option has been added to the
svnadmin load command.
This option can be used to dramatically speed up the load process when
there is no need to ensure that the resulting data survives a system crash
or power loss, e.g. when loading a dump file into a fresh repository.

 


New --normalize-props option for svnadmin load
  ¶


A new --normalize-props option has been added to the
svnadmin load command. This option can be used to automatically
repair non-LF line endings in properties
such as svn:log or svn:ignore.  Such invalid line endings
were accepted by older servers and can be found in repository dumps of older
repositories, but are rejected by Subversion 1.6 and later.

Calling svnadmin load with --normalize-props will
automatically repair all invalid property line endings found in the dumpstream,
thus ensuring that the appropriate values are loaded into the repository.

 


New svnadmin dump-revprops and svnadmin load-revprops subcommands
  ¶


svnadmin can now dump and load revision properties independently of
other changes made to the repository. This is useful because revision
properties are not versioned but their values may change if the administrator
has configured the repository's pre-revprop-change hook.

svnadmin dump-revprops will save the current values of all revision
properties to a dump file. svnadmin load-revprops can be used to set
revision properties in a repository to the values saved in a dump file.


svnadmin dump can now include or exclude paths
  (issue #4729)
  ¶


New --include and --exclude options have been added to the
svnadmin dump command.
Using --exclude or --include gives results equivalent to authz-based
path exclusions. In particular, when the source of a copy is excluded,
the copy is transformed into an add (unlike in 'svndumpfilter').

A --pattern option allows the include or exclude rules to contain
wildcards (the same as in 'svndumpfilter').

 

 

 


Client- and server-side improvements
  ¶




RA-serf now compresses deltas when possible
  ¶


RA-serf now sends deltas compressed when possible, unless compression is
disabled by the 'http-compression = no' client configuration option.
This is enabled for servers that advertise support for this specific (new)
capability.

mod_dav_svn servers now advertise this specific (new) capability.Ref. r1704317,
r1704891,
r1791290. 

 

 

  


Known issues in the release
  ¶


There are some known issues in the Subversion 1.10 releases.  These
may be fixed in later 1.10.x releases.  Selected issues are listed here;
see the issue
tracker for details and for other issues.



  SVN-4741:
  authz group cannot refer to multiple groups
  ¶

Broken in 1.10.0. Fixed in 1.10.1.




  SVN-4762:
  authz doesn't combine global and repository rules
  ¶

Broken in 1.10.0 and 1.10.1.  See also
  path-based authorization compatibility.


  




Subversion 1.9.x is now the old stable version
  ¶


The Subversion 1.9.x line is now the old stable version.  This means
that 1.9.x will still receive security relevant fixes as well as
bugfixes. While we will evaluate any bugreport with regards to its
severity, there might be issues with a lower severity which will
only get fixed in 1.10.x, particularly if the patches would be invasive,
destabilizing, and/or require a significant investment to get backported to the
old stable version.

Therefore, if you are running into an issue with the old stable
version which has already been fixed in the latest version, we might
ask you to upgrade to that version to resolve the issue.

  


Subversion 1.8.x is end of life
  ¶


The Subversion 1.8.x line is end of life (EOL).
This doesn't
mean that your 1.8 installation is doomed; if it works well and is all
you need, that's fine.  "End of life" just means we've stopped
accepting bug reports against 1.8.x versions, and will not make any
more 1.8.x releases.

  


