www/svn_1.1_releasenotes.html - subversion - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <style type="text/css"> /* <![CDATA[ */
   @import "branding/css/tigris.css";
   @import "branding/css/inst.css";
   /* ]]> */</style>
 <link rel="stylesheet" type="text/css" media="print"
   href="branding/css/print.css"/>
 <script type="text/javascript" src="branding/scripts/tigris.js"></script>
 <title>Subversion 1.1 Release Notes</title>
 </head>

 <body>
 <div class="app">

 <h1 style="text-align: center">Subversion 1.1 Release Notes</h1>
 <h2 style="text-align: center">(and State of the Project)</h2>

 <p>The <a href="http://svnbook.red-bean.com">Subversion book site</a>
 has now been forked, and a separate <a
 href="http://svnbook.red-bean.com/svnbook-1.1/index.html">Subversion
 1.1 book</a> documents most of <a
 href="http://svnbook.red-bean.com/svnbook-1.1/pr02s07.html">the new
 1.1 features</a>.  Still, here are some brief release notes.</p>

 <h3>Overview</h3>

 <p>Subversion 1.1 can best be summarized as: (1) an optional new
 non-database repository back-end, and (2) a whole slew of client-side
 improvements.  Details are given below.</p>

 <p>Note that Subversion 1.1 is a superset of all the Subversion 1.0.x
 releases.  The 1.0.x releases contain nothing but critical bugfixes
 backported from the 1.1 development line.  Subversion 1.1 introduces
 new features and fixes many smaller bugs.</p>

 <h3>Compatibility Concerns</h3>

 <p>Subversion's compatibility and version-numbering policy is
     documented in the
     <a href="hacking.html#release-numbering">Hacker's Guide to
     Subversion</a>.  Here's a quick summary:</p>

 <ul>

 <li><p><em>Database schema</em>: if upgrading to Subversion 1.1, there
         is <strong>no need</strong> to dump and load your repository.
         There will be no changes requiring dump/load before Subversion
         2.0.</p></li>

 <li><p><em>Client/server compatibility</em>: a 1.X client and 1.Y
         server are always interoperable.  However, the latest features
         or bugfixes may not be available unless both client and server
         are the latest version.</p></li>

 <li><p><em>API/ABI compatibility</em>: the 1.1 release only adds new
         functions; thus a 1.0 program can both compile against and
         use 1.1 libraries at run-time, but a 1.1 program cannot use
         1.0 libraries.</p></li>

 </ul>


 <h3>New Major Features</h3>

 <h4>Non-database repositories  (<em>new server feature</em>)</h4>

 <p>It's now possible to create repositories that don't use a
    BerkeleyDB database.  Instead, these new repositories store data in
    the ordinary filesystem.  Because Subversion developers often refer
    to the repository as "The Filesystem", we have adopted the rather
    confusing habit of referring to these new repositories as "fsfs"
    repositories... that is, a Filesystem implementation that uses the
    OS filesystem to store data.</p>

 <p>Note that the data files created by fsfs repositories are still in
    a binary format, and are not human editable!</p>

 <p>Why would someone choose an fsfs repository over BerkeleyDB?  The
    immediate and obvious advantages are the ability to access a
    repository over a network filesystem, and no more database "wedges"
    needing recovery.  You can read the full list of
    advantages/disadvantages at <a
    href="http://svn.collab.net/repos/svn/trunk/notes/fsfs"
         >http://svn.collab.net/repos/svn/trunk/notes/fsfs</a></p>

 <p>To create an fsfs repository, simply run <tt>'svnadmin create
       --fs-type fsfs'</tt>.  Or, if BerkeleyDB wasn't detected at
     compile time, <tt>'svnadmin create'</tt> will default to type
     fsfs.</p>


 <h4>Symlink versioning (<em>new client feature</em>)</h4>

 <p>This feature allows unix users to place symlinks under version
     control.  (Note: this is <em>not</em> about creating links
     inside a repository that point to other parts of the repository!)</p>

 <p> When a user adds a unix symlink to version control and commits,
     the repository stores the object as a file with the "svn:special"
     property attached.  When the client sees this property during
     checkouts and updates, the repository file is translated back into
     a symlink within the working copy.  On win32 systems, the client
     does no translation, and the user sees just an ordinary file.
     (But a win32 user can hand-edit the contents of this file, which
     will still have an affect of changing the symlink on a unix
     system.)</p>


 <h4>Client follows renames  (<em>new client feature</em>)</h4>

 <p>Subversion makes a lot of noise about the way branches (copies) of
     files and directories maintain historical connections to their
     source, but in Subversion 1.0 only <tt>'svn log'</tt> actually
     follows that history, not <tt>'svn diff'</tt>, <tt>'svn
     merge'</tt>, <tt>'svn list'</tt>, or <tt>'svn cat'</tt>.</p>

 <p> This problem (<a href="">issue 1093</a>) is now fixed in
     Subversion 1.1.  All client subcommands now transparently trace
     backwards through renames when examining older versions of files
     and directories.</p>


 <h4>Command line auto-escaping of URI and IRIs (<em>new client
 feature</em>)</h4>

 <p>In the 1.0 command line client, users had to escape URLs manually.
     The client only accepted "legally correct" URLs, such as</p>
 <pre>
   svn checkout http://host/path%20with%20space/project/espa%C3%B1a
 </pre>
 <p>The 1.1 command line client now knows how to do what web-browsers
     have been doing for long time: it auto-escapes characters like
     spaces and other upper-ASCII i18n characters.</p>
 <pre>
   svn checkout "http://host/path with space/project/espa&ntilde;a"
 </pre>
 <p>The definition of an Internationalized URI (IRI) is still a work in
     progress; see <a
     href="http://www.w3.org/International/iri-edit/">the draft spec</a>.</p>


 <h4>Localized messages  (<em>new client feature</em>)</h4>

 <p>Subversion 1.1 is now using gettext() to display translated error,
    informational, and help messages to the user.  We currently have
    translations for German, Spanish, Polish, Swedish, Norwegian
    Bokmal, Traditional Chinese, Japanese, and Brazilian Portuguese,
    and we're looking for volunteers to write translations for
    other languages.  To localize your Subversion client, just set your
    LANG environment variable:</p>

      <pre>
        $ export LANG=de_DE
        $ svn help cat
        cat: Ausgabe des Inhaltes der angegebenen Dateien oder URLs
        Aufruf: cat ZIEL...
        [...]
      </pre>


 <h3>Other Improvements</h3>

 <h4>Speed optimizations: (<em>requires both new client and server</em>)</h4>
 <p>Faster <tt>checkout</tt>, <tt>update</tt>, <tt>status</tt>, and
       <tt>blame</tt> commands.</p>

 <h4>Shareable working copies:  (<em>client fix</em>)</h4>

 <p>There have been historical problems with permissions when multiple
 users share a working copy.  We believe these problems to be fixed
 now, see <a
 href="http://subversion.tigris.org/issues/show_bug.cgi?id=1509">issue
 #1509</a>.</p>

 <h4>New 'store-passwords' runtime variable:  (<em>new client feature</em>)</h4>

 <p>The previous <tt>store-auth-creds</tt> runtime variable still
 works, but many users were unhappy with it.  It disables <b>all</b>
 credentials caching on local disk: passwords, usernames, server certs.
 This new runtime variable only disables password caching, so that
 server certificates can still be remembered.</p>

 <h4>Bugfixes:</h4>
 <p>More than 40 "small" bugs fixed.  See the <a
 href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
       for details.</p>

 <h4>New subcommand switches:</h4>
    <dl>
       <dt><tt>svn blame --verbose</tt></dt>
       <dd>show extra annotation information</dd>

       <dt><tt>svn export --native-eol [LF | CRLF]</tt></dt>
       <dd>forcibly export 'svn:eol-style=native' files with a specific
       line ending, either LF or CRLF.  Useful for releases (say,
       creating a win32 zipfile on unix.)</dd>

       <dt><tt>svn add --force</tt></dt> <dd>forcibly recurse into
       already-versioned directories.  This allows users to <tt>svn
       add</tt> every unversioned object, even those hiding deep within a
       working copy.</dd>

       <dt><tt>svnadmin dump --deltas</tt></dt>
       <dd>Creates a smaller dumpfile by including compressed binary
       diffs, rather than fulltexts.</dd>

       <dt><tt>svnadmin create --fs-type [fsfs | bdb]</tt></dt>
       <dd>Create a repository using either 'fsfs' or 'bdb' backend,
       defaults is 'bdb'.</dd>

       <dt><tt>svnadmin recover [--wait]</tt></dt>
       <dd>This command now exits immediately if another process has a
       lock on the repository.  Use the new <tt>--wait</tt> option to
       get the old behavior (where svnadmin blocks indefinitely until
       the lock is freed.)</dd>

       <dt><tt>svnserve --tunnel-user=NAME</tt></dt>
       <dd>Used in conjuction with <tt>--tunnel</tt> switch;  tells
       svnserve to assume that NAME is the authenticated user, rather
       than the UID of the svnserve process.  Useful for users wishing
       to share a single system account over SSH, but maintaining
       separate commit identities.</dd>

       <dt><tt>svndumpfilter --quiet</tt></dt>
       <dd>less chatty dumpfiltering.</dd>

       <dt><tt>svnserve      --version</tt><br/>
           <tt>svnversion    --version</tt><br/>
           <tt>svndumpfilter --version</tt></dt>
       <dd>display version of program.</dd>

    </dl>


 <h3>Developer Changes</h3>

 <p>A number of new 1.1 functions have been introduced, with the "2"
 suffix, and the older versions are now marked deprecated (and will be
 removed in Subversion 2.0).  For example, a new svn_wc_diff2()
 function has superseded svn_wc_diff().  See the <a
 href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
 for details.</p>

 <p>There has been extensive work on the python, perl, and java
 bindings.  More coverage, more functionality, and they're now fully
 integrated into the main Subversion build system (just run 'make
 swig-py' or 'make swig-pl' or 'make javahl').</p>


 <h3>Testimonials and Roadmap</h3>

 <p>See our <a href="roadmap.html">roadmap</a> for what the future
 looks like.</p>

 <p>If you're looking for testimonials on Subversion, see our new <a
 href="http://subversion.tigris.org/testimonials.html">testimonials
 page</a>.</p>

 <p>As usual, you can find links to other
 Subversion-related sites, projects, and essays on our <a
 href="http://subversion.tigris.org/links.html">links
 page</a>.</p>

 </div>
 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<style type="text/css"> /* <![CDATA[ */
	@import "branding/css/tigris.css";
	@import "branding/css/inst.css";
	/* ]]> */</style>
	<link rel="stylesheet" type="text/css" media="print"
	href="branding/css/print.css"/>
	<script type="text/javascript" src="branding/scripts/tigris.js"></script>
	<title>Subversion 1.1 Release Notes</title>
	</head>

	<body>
	<div class="app">

	<h1 style="text-align: center">Subversion 1.1 Release Notes</h1>
	<h2 style="text-align: center">(and State of the Project)</h2>

	<p>The <a href="http://svnbook.red-bean.com">Subversion book site</a>
	has now been forked, and a separate <a
	href="http://svnbook.red-bean.com/svnbook-1.1/index.html">Subversion
	1.1 book</a> documents most of <a
	href="http://svnbook.red-bean.com/svnbook-1.1/pr02s07.html">the new
	1.1 features</a>. Still, here are some brief release notes.</p>

	<h3>Overview</h3>

	<p>Subversion 1.1 can best be summarized as: (1) an optional new
	non-database repository back-end, and (2) a whole slew of client-side
	improvements. Details are given below.</p>

	<p>Note that Subversion 1.1 is a superset of all the Subversion 1.0.x
	releases. The 1.0.x releases contain nothing but critical bugfixes
	backported from the 1.1 development line. Subversion 1.1 introduces
	new features and fixes many smaller bugs.</p>

	<h3>Compatibility Concerns</h3>

	<p>Subversion's compatibility and version-numbering policy is
	documented in the
	<a href="hacking.html#release-numbering">Hacker's Guide to
	Subversion</a>. Here's a quick summary:</p>

	<ul>

	<li><p><em>Database schema</em>: if upgrading to Subversion 1.1, there
	is <strong>no need</strong> to dump and load your repository.
	There will be no changes requiring dump/load before Subversion
	2.0.</p></li>

	<li><p><em>Client/server compatibility</em>: a 1.X client and 1.Y
	server are always interoperable. However, the latest features
	or bugfixes may not be available unless both client and server
	are the latest version.</p></li>

	<li><p><em>API/ABI compatibility</em>: the 1.1 release only adds new
	functions; thus a 1.0 program can both compile against and
	use 1.1 libraries at run-time, but a 1.1 program cannot use
	1.0 libraries.</p></li>

	</ul>


	<h3>New Major Features</h3>

	<h4>Non-database repositories (<em>new server feature</em>)</h4>

	<p>It's now possible to create repositories that don't use a
	BerkeleyDB database. Instead, these new repositories store data in
	the ordinary filesystem. Because Subversion developers often refer
	to the repository as "The Filesystem", we have adopted the rather
	confusing habit of referring to these new repositories as "fsfs"
	repositories... that is, a Filesystem implementation that uses the
	OS filesystem to store data.</p>

	<p>Note that the data files created by fsfs repositories are still in
	a binary format, and are not human editable!</p>

	<p>Why would someone choose an fsfs repository over BerkeleyDB? The
	immediate and obvious advantages are the ability to access a
	repository over a network filesystem, and no more database "wedges"
	needing recovery. You can read the full list of
	advantages/disadvantages at <a
	href="http://svn.collab.net/repos/svn/trunk/notes/fsfs"
	>http://svn.collab.net/repos/svn/trunk/notes/fsfs</a></p>

	<p>To create an fsfs repository, simply run <tt>'svnadmin create
	--fs-type fsfs'</tt>. Or, if BerkeleyDB wasn't detected at
	compile time, <tt>'svnadmin create'</tt> will default to type
	fsfs.</p>


	<h4>Symlink versioning (<em>new client feature</em>)</h4>

	<p>This feature allows unix users to place symlinks under version
	control. (Note: this is <em>not</em> about creating links
	inside a repository that point to other parts of the repository!)</p>

	<p> When a user adds a unix symlink to version control and commits,
	the repository stores the object as a file with the "svn:special"
	property attached. When the client sees this property during
	checkouts and updates, the repository file is translated back into
	a symlink within the working copy. On win32 systems, the client
	does no translation, and the user sees just an ordinary file.
	(But a win32 user can hand-edit the contents of this file, which
	will still have an affect of changing the symlink on a unix
	system.)</p>


	<h4>Client follows renames (<em>new client feature</em>)</h4>

	<p>Subversion makes a lot of noise about the way branches (copies) of
	files and directories maintain historical connections to their
	source, but in Subversion 1.0 only <tt>'svn log'</tt> actually
	follows that history, not <tt>'svn diff'</tt>, <tt>'svn
	merge'</tt>, <tt>'svn list'</tt>, or <tt>'svn cat'</tt>.</p>

	<p> This problem (<a href="">issue 1093</a>) is now fixed in
	Subversion 1.1. All client subcommands now transparently trace
	backwards through renames when examining older versions of files
	and directories.</p>


	<h4>Command line auto-escaping of URI and IRIs (<em>new client
	feature</em>)</h4>

	<p>In the 1.0 command line client, users had to escape URLs manually.
	The client only accepted "legally correct" URLs, such as</p>
	<pre>
	svn checkout http://host/path%20with%20space/project/espa%C3%B1a
	</pre>
	<p>The 1.1 command line client now knows how to do what web-browsers
	have been doing for long time: it auto-escapes characters like
	spaces and other upper-ASCII i18n characters.</p>
	<pre>
	svn checkout "http://host/path with space/project/españa"
	</pre>
	<p>The definition of an Internationalized URI (IRI) is still a work in
	progress; see <a
	href="http://www.w3.org/International/iri-edit/">the draft spec</a>.</p>



	<h4>Localized messages (<em>new client feature</em>)</h4>

	<p>Subversion 1.1 is now using gettext() to display translated error,
	informational, and help messages to the user. We currently have
	translations for German, Spanish, Polish, Swedish, Norwegian
	Bokmal, Traditional Chinese, Japanese, and Brazilian Portuguese,
	and we're looking for volunteers to write translations for
	other languages. To localize your Subversion client, just set your
	LANG environment variable:</p>

	<pre>
	$ export LANG=de_DE
	$ svn help cat
	cat: Ausgabe des Inhaltes der angegebenen Dateien oder URLs
	Aufruf: cat ZIEL...
	[...]
	</pre>


	<h3>Other Improvements</h3>

	<h4>Speed optimizations: (<em>requires both new client and server</em>)</h4>
	<p>Faster <tt>checkout</tt>, <tt>update</tt>, <tt>status</tt>, and
	<tt>blame</tt> commands.</p>

	<h4>Shareable working copies: (<em>client fix</em>)</h4>

	<p>There have been historical problems with permissions when multiple
	users share a working copy. We believe these problems to be fixed
	now, see <a
	href="http://subversion.tigris.org/issues/show_bug.cgi?id=1509">issue
	#1509</a>.</p>

	<h4>New 'store-passwords' runtime variable: (<em>new client feature</em>)</h4>

	<p>The previous <tt>store-auth-creds</tt> runtime variable still
	works, but many users were unhappy with it. It disables <b>all</b>
	credentials caching on local disk: passwords, usernames, server certs.
	This new runtime variable only disables password caching, so that
	server certificates can still be remembered.</p>

	<h4>Bugfixes:</h4>
	<p>More than 40 "small" bugs fixed. See the <a
	href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
	for details.</p>

	<h4>New subcommand switches:</h4>
	<dl>
	<dt><tt>svn blame --verbose</tt></dt>
	<dd>show extra annotation information</dd>

	<dt><tt>svn export --native-eol [LF \| CRLF]</tt></dt>
	<dd>forcibly export 'svn:eol-style=native' files with a specific
	line ending, either LF or CRLF. Useful for releases (say,
	creating a win32 zipfile on unix.)</dd>

	<dt><tt>svn add --force</tt></dt> <dd>forcibly recurse into
	already-versioned directories. This allows users to <tt>svn
	add</tt> every unversioned object, even those hiding deep within a
	working copy.</dd>

	<dt><tt>svnadmin dump --deltas</tt></dt>
	<dd>Creates a smaller dumpfile by including compressed binary
	diffs, rather than fulltexts.</dd>

	<dt><tt>svnadmin create --fs-type [fsfs \| bdb]</tt></dt>
	<dd>Create a repository using either 'fsfs' or 'bdb' backend,
	defaults is 'bdb'.</dd>

	<dt><tt>svnadmin recover [--wait]</tt></dt>
	<dd>This command now exits immediately if another process has a
	lock on the repository. Use the new <tt>--wait</tt> option to
	get the old behavior (where svnadmin blocks indefinitely until
	the lock is freed.)</dd>

	<dt><tt>svnserve --tunnel-user=NAME</tt></dt>
	<dd>Used in conjuction with <tt>--tunnel</tt> switch; tells
	svnserve to assume that NAME is the authenticated user, rather
	than the UID of the svnserve process. Useful for users wishing
	to share a single system account over SSH, but maintaining
	separate commit identities.</dd>

	<dt><tt>svndumpfilter --quiet</tt></dt>
	<dd>less chatty dumpfiltering.</dd>

	<dt><tt>svnserve --version</tt><br/>
	<tt>svnversion --version</tt><br/>
	<tt>svndumpfilter --version</tt></dt>
	<dd>display version of program.</dd>

	</dl>


	<h3>Developer Changes</h3>

	<p>A number of new 1.1 functions have been introduced, with the "2"
	suffix, and the older versions are now marked deprecated (and will be
	removed in Subversion 2.0). For example, a new svn_wc_diff2()
	function has superseded svn_wc_diff(). See the <a
	href="http://svn.collab.net/repos/svn/trunk/CHANGES">CHANGES</a> file
	for details.</p>

	<p>There has been extensive work on the python, perl, and java
	bindings. More coverage, more functionality, and they're now fully
	integrated into the main Subversion build system (just run 'make
	swig-py' or 'make swig-pl' or 'make javahl').</p>


	<h3>Testimonials and Roadmap</h3>

	<p>See our <a href="roadmap.html">roadmap</a> for what the future
	looks like.</p>

	<p>If you're looking for testimonials on Subversion, see our new <a
	href="http://subversion.tigris.org/testimonials.html">testimonials
	page</a>.</p>

	<p>As usual, you can find links to other
	Subversion-related sites, projects, and essays on our <a
	href="http://subversion.tigris.org/links.html">links
	page</a>.</p>

	</div>
	</body>
	</html>