Apache Subversion 1.8 Release Notes

XXX(1.7) Improved output of svn update for multiple working copies ¶

Improvements have been made to the output of svn update when updating multiple working copies at once (see issue #3693). Below is an example of the new output:

  $ svn up subversion svncorp UNVERSIONED
  Updating 'subversion':
  At revision 1037740.
  Updating 'svncorp':
  At revision 288.
  Skipped 'UNVERSIONED'
  Summary of updates:
   Updated 'subversion' to r1037740.
   Updated 'svncorp' to r288.
  Summary of conflicts:
   Skipped paths: 1

FS paths syntax in authz access rules ¶

Prior to this release, the section headers in Subversion's authz access files—which contain repository names and repository filesystem paths—accepted section headers that would never be looked up, because the repository filesystem path (such as /trunk/secretdir) embedded in the section header is formatted differently from how Subversion formats those paths when it looks them up in the file. Subversion 1.7 and earlier would silently ignore those sections of the authz file; directives in those sections would never apply.

That's been fixed in this release: Subversion will now error out if a section header contains a repository filesystem path that either does not begin with a slash or contains two consecutive slashes. The practical fallout, though, is that your existing authz files might be depending (perhaps unintentionally) on the old behavior and the new behavior could result in all access to items in your repositories being unexpectedly denied as a result of upgrading to Subversion 1.8. The svnauthz-validate tool, when linked to Subversion 1.8 libraries, can be used to test an authz file for validity. (The tool will error out on a file that the Subversion server will error out on.)

FSFS 'svnadmin verify' finds mergeinfo-count and predecessor-count discrepancies ¶

Up to 1.7.0, Subversion could create erroneous metadata on nodes in a FSFS-backed repository in certain situations involving concurrent commit attempts. (Only metadata was affected; file contents and properties was not.) As of 1.7.1 Subversion prevents new instances of the corruption, but only as of 1.8.0 does 'svnadmin verify' detect instances of that corruption in the history of a repository.

The fix to these issues is simple: perform a dump/load cycle. (As usual, svnsync can be used instead of dump/load.) The cycle can be done with any version of Subversion, and after the cycle the repository should be served exclusively by Subversion 1.7.5 or newer to prevent further instances of the bug from entering the repository.

See this summary of issue #4129 for more information about these problems.

Operating on files not in any changelist ¶

When using changelists in the working copy, so far there has been no convenient way to refer to the set of files which do not belong to any changelist. Subversion 1.8 allows such files to be referred to as members of the pseudo-changelist whose name is the empty string:

   $ svn status
   M       iota
   
   --- Changelist 'mylist':
   M       A/mu
   $ svn status --changelist ""
   M       iota
   $ svn status --changelist mylist
   
   --- Changelist 'mylist':
   M       A/mu
   $

Since directories cannot be added to changelists, they will always be considered members of the "" changelist. Thus, when using the "" changelist with an operation which defaults to being recursive (such as svn status or svn commit), it might be desirable to prevent the operation from recursing on such directories by passing --depth=empty.

TODO: should the behaviour of directories with respect to membership in the "" changelist be changed?

It is not possible to add items to the "" pseudo-changelist; attempting to do so will cause the client library to raise an error:

   $ svn changelist "" iota  
   svn: E125014: Target changelist name must not be empty

Star-imports in the SWIG-Python bindings ¶

The swig-py bindings have been patched to make *-imports of submodules to do the right thing: from svn.client import * will now import only symbols beginning with svn_ or SVN_. (Most of these symbols will be svn_client_* symbols, of course.) Star-imports of from svn have not changed (they import just the bare submodule names: 'fs', 'ra', etc), and star imports of from svn.core currently imports some select symbols (notably 'Pool').

This change is incompatible: code that expected symbols such as 'commit_txn' (in 'fs') and 'apr_initialize' to be pulled by a star-import will have to change. We will consider amending the list of symbols exported to a star-import as needed.

XXX(1.7) Reduced subtree mergeinfo changes ¶

Merges no longer record mergeinfo (describing the merge) on subtrees (that have their own explicit mergeinfo), if the subtree was unaffected by the merge. This should greatly reduce the number of spurious svn:mergeinfo property changes for users who have large numbers of sutrees with explicit mergeinfo.

post-commit hook grows txn-name argument ¶

The post-commit hook has grown a txn-name argument as the third positional argument (argv[3]). This argument is the name of the transaction that has become the revision triggering the post-commit hook; it is the same as the second positional argument to the pre-commit, and thus enables the pre-commit and post-commit hooks to easily transfer state between them.

Generically, if the pre-commit hook makes an expensive computation against the would-be-revision, it can store the result of that computation in a persistent hash keyed by the transaction name, which the post-commit hook will use to avoid re-doing the computation. One concrete usage of this would be to implement a pre-commit hook that tests compilability only, while a post-commit hook or a continuous integration tool runs more thorough tests --- on the binaries built at pre-commit, without having to rebuild them itself.