Subversion 1.6 Release Notes

Working Copy Upgrades

WARNING: if a Subversion 1.6 client encounters a pre-1.6 working copy, it will automatically upgrade the working copy format as soon as it touches it, making it unreadable by older Subversion clients. If you are using several versions of Subversion on your machine, be careful about which version you use in which working copy, to avoid accidentally upgrading a working copy. (But note that this "auto upgrade" behavior does not occur with the repositories, only working copies.)

If you accidentally upgrade a 1.5 working copy to 1.6, and wish to downgrade back to 1.5, use the change-svn-wc-format.py script. See this FAQ entry for details, and run the script with the --help option for usage instructions.

Repository Upgrades

The Subversion 1.6 server works with 1.5 and older repositories, and it will not upgrade such repositories to 1.6 unless specifically requested to via the svnadmin upgrade command. This means that some of the new 1.6 features will not become available simply by upgrading your server: you will also have to upgrade your repositories. (We decided not to auto-upgrade repositories because we didn't want 1.6 to silently make repositories unusable by 1.5 — that step should be a conscious decision on the part of the repository admin.)

Improved output of svn proplist --verbose

XXX(r32484): The output of svn proplist --verbose has been improved.

   $ svn proplist --verbose build.conf
   Properties on 'build.conf':
     svn:eol-style
       native
     svn:mergeinfo
       /trunk/build.conf:1-4800
       /branches/a/build.conf:3000-3400
       /branches/b/build.conf:3200-3600
   $ 

Changed output of svn status

The output of svn status contains the additional seventh column which informs whether the item is the victim of a tree conflict. An additional line with more detailed description of a tree conflict is displayed after each item remaining in tree conflict.

   $ svn status
   M       Makefile.in
   A     C src/error.c
         >   local add, incoming add upon update
   M       src/log.c
   M     C src/path.c
         >   local edit, incoming delete upon update
   D     C src/properties.c
         >   local delete, incoming edit upon merge
   M     C src/time.c
   $ 

Changed handling of output of pre-lock hook

XXX(r32778)

Prompting before storing passwords in plaintext form

Subversion prompts before storing passwords in plaintext form.

Example:

   $ svn checkout https://www.example.com/repository/trunk repository_trunk
   Authentication realm: <https://www.example.com> Example
   Password for 'user':
   -----------------------------------------------------------------------
   ATTENTION!  Your password for authentication realm:

      <https://www.example.com> Example

   can only be stored to disk unencrypted!  You are advised to configure
   your system so that Subversion can store passwords encrypted, if
   possible.  See the documentation for details.

   You can avoid future appearances of this warning by setting the value
   of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
   '/home/user/.subversion/servers'.
   -----------------------------------------------------------------------
   Store password unencrypted (yes/no)?

Support for storing passwords in KWallet and GNOME Keyring (Unix-like systems)

Passwords can be stored in KWallet (KDE 4) and GNOME Keyring.

Support for storing SSL client certificate passphrases

SSL client certificate passphrases can be stored in KWallet, GNOME Keyring, Mac OS Keychain, a Windows CryptoAPI encrypted form or in plaintext form.

Further reading

See The svn:externals section of the Subversion Book.

Sharing multiple common representations (issue 2286, server)

XXX:When using many branches and merging between them often, it is common to have files with similar lines of history which contain the exact same content. In the past, Subversion has stored these files as deltas against previous versions of the file. Subversion 1.6 will now use existing representations in the filesystem for duplicate storage. Depending on the size of the repository, and the degree of branching and merging, this can cause an up to 20% space reduction for Berkeley DB repositories and a 15% reduction for FSFS repositories.

FSFS repositories: Packing completed shards (server)

Subversion 1.5 introduced the ability for FSFS repositories to be sharded into multiple directories for revision and revprop files. Subversion 1.6 takes the sharding concept further, and allows full shard directories to be packed into a single file. By reducing internal fragmentation in the filesystem, packed FSFS repositories have significant space savings over their unpacked counterparts, especially repositories which contain many small commits. Using a one-file-per-shard approach also allows Subversion to reduce disk I/O and better exploit operating system caches.

To pack a repository, run svnadmin pack on the repository. Once a repository has been packed, there is no migration path back to an unpacked state, and it can only be read by Subversion 1.6 or greater servers.

FSFS repositories: Support for Memcached (server)

XXX: Memcached can cache data of FSFS repositories.

Additional build-time dependencies: APR-Util ≥1.3 || ( APR-Util < 1.3 && APR_Memcache )

BDB repositories: Reverse deltas (server)

XXX

--trust-server-cert option

XXX