Google Git
Sign in
apache / subversion / b71bf15ca2b1128e8a6be2eafe6c6202f88bf354 / . / www / faq.html
blob: c9a7e48f7119764de9e689cf9f5123aaebb9d7d3 [file] [log] [blame]
<!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>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<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 FAQ</title>
</head>
<body>
<div class="app">
<h1>Subversion FAQ</h1>
<div class="h2"><!-- no 'id' or 'title' attribute for TOC -->
<h2>Table of Contents</h2>
<h4>General questions:</h4>
<ul>
<li><a href="#why">Why does this project exist?</a></li>
<li><a href="#collab">Is Subversion proprietary? I heard that it
belongs to CollabNet.</a></li>
<li><a href="#stable">Is Subversion stable enough for me to use for my
own projects?</a></li>
<li><a href="#interop">What is Subversion's client/server interoperability
policy?</a></li>
<li><a href="#portability">What operating systems does Subversion run
on?</a></li>
<li><a href="#filesystem">What's all this about a new filesystem? Is
it like ext2?</a></li>
<li><a href="#server-requirements">What kind of hardware do I need to run
a Subversion server?</a></li>
<li><a href="#apache-extension">I heard that Subversion is an Apache
extension? What does it use for servers?</a></li>
<li><a href="#need-apache">Does this mean I have to set up Apache to
use Subversion?</a></li>
<li><a href="#multiple-apachim">I run Apache 1.x right now, and can't
switch to Apache 2.0 just to serve Subversion repositories.
Does that mean I can't run a Subversion server?</a></li>
<li><a href="#feature-x">Why don't you do X, just like SCM system Y?</a></li>
<li><a href="#globalrev">Why does the entire repository share the
same revision number? I want each of my projects to have their
own revision numbers. </a></li>
<li><a href="#changesets">Does Subversion have changesets?</a></li>
<li><a href="#release">When's the next release?</a></li>
<li><a href="#symlinks">Does Subversion support symlinks?</a></li>
<li><a href="#logo">I need a high resolution version of the Subversion logo,
where can I get it?</a></li>
<li><a href="#more-information">I have other questions. Where can I
get more information?</a></li>
<li><a href="#moderation">Why isn't my post showing up on the mailing
list?</a></li>
</ul>
<h4>How-to:</h4>
<ul>
<li><a href="#co-svn">How do I check out the Subversion code?</a></li>
<li><a href="#repository">How do I create a repository? How do I
import data into it?</a></li>
<li><a href="#cvs2svn">How do I convert an existing CVS repository
into a Subversion repository?</a></li>
<li><a href="#proxy">What if I'm behind a proxy?</a></li>
<li><a href="#paranoid">My admins don't want me to have a HTTP server for
Subversion. What can I do if I still want remote usage?</a></li>
<li><a href="#multi-proj">How do I manage several different projects
under Subversion?</a></li>
<li><a href="#multi-merge">How do I merge two completely separate repositories?</a></li>
<li><a href="#nfs">Should I store my repository / working copy on a
NFS server?</a></li>
<li><a href="#bdblogs">Why is my repository taking up so much disk space?</a></li>
<li><a href="#reposperms">How do I set repository permissions correctly?</a></li>
<li><a href="#readonly">Why do read-only operations still need repository write access?</a></li>
<li><a href="#removal">How do I completely remove a file from the repository's history?</a></li>
<li><a href="#change-log-msg">How do I change the log message for a revision
after it's been committed?</a></li>
<li><a href="#patch">How do I submit a patch for Subversion?</a></li>
<li><a href="#in-place-import">How can I do an in-place 'import'
(i.e. add a tree to Subversion such that the original data becomes
a working copy directly)?</a></li>
<li><a href="#dumpload">What is this "dump/load cycle" people
sometimes talk about when upgrading a Subversion server?</a></li>
<li><a href="#sspi">How do I allow clients to authenticate against a
Windows domain controller using SSPI Authentication?</a></li>
<li><a href="#adm-dir">I don't like the ".svn" directory name, and
prefer "SVN" or something else. How do I change it?</a></li>
<li><a href="#case-change">How do I change the case of a filename?</a></li>
<li><a href="#merge-using-tags">I can't use tags to merge changes from a
branch into the trunk like I used to with CVS, can I?</a></li>
<li><a href="#version-value-in-source">Why doesn't the $Revision$
keyword do what I want? It expands to the file's last-changed
revision, but I want something that will expand to the file's
current revision.</a></li>
<li><a href="#log-in-source">Does Subversion have a keyword which behaves
like $Log$ in CVS?</a></li>
<li><a href="#ignore-commit">I have a file in my project that every
developer must change, but I don't want those local mods to ever be
committed. How can I make 'svn commit' ignore the file?</a></li>
<li><a href="#ssh-auth-cache">When I access a repository using
svn+ssh, my password is not cached in ~/.subversion/auth/. How do
I avoid having to type it so often?</a></li>
<li><a href="#ssh-svnserve-location">My
<tt>svnserve</tt> binary is in a directory that isn't on my
users' default <tt>PATH</tt>s, they use svn+ssh, and I can't figure
out how to modify their <tt>PATH</tt> so that they can run <tt>svnserve</tt>.</a></li>
<li><a href="#ssh-authorized-keys-trick">
I want to allow access via svn+ssh://, but am paranoid. I hate the
idea of giving each user a login; I would then have to worry about
what they are, and are not, allowed to access on my machine.
</a></li>
<li><a href="#auto-props">How can I set certain properties on
everything in the repository? Also, how can I make sure that every
new file coming into the repository has these properties?</a></li>
<li><a href="#svn-editor">How do I handle spaces in the editor path?</a></li>
<li><a href="#divining-bdb-version">How do I determine which version of
Berkeley DB a repository is using?</a></li>
<li><a href="#website-auto-update">I'm managing a website in my
repository. How can I make the live site automatically update after
every commit?</a></li>
<li><a href="#single-file-checkout">How do I check out a single
file?</a></li>
<li><a href="#wc-change-detection">How do I detect adds, deletes,
copies and renames in a working copy after they've already
happened?</a></li>
<li><a href="#svnserve-win-service">How do I run svnserve as a service
on Windows?</a></li>
<li><a href="#bdb-fsfs-convert">How do I convert my repository from using BDB
to FSFS or from FSFS to BDB?</a></li>
<li><a href="#binary-files">How does Subversion handle binary files?</a></li>
<li><a href="#terse-diff">How can I make <tt>svn diff</tt> show me
just the names of the changed files, not their contents?</a></li>
<li>
<a href="#sorry-no-globbing">How can I use wildcards or globbing to move many files at once?</a>
</li>
<li><a href="#vendor-branch">How can I maintain a modified version (a
"vendor branch") of third-party software using Subversion?</a></li>
</ul>
<h4>Troubleshooting:</h4>
<ul>
<li><a href="#stuck-bdb-repos">My repository seems to get stuck all the
time, giving me errors about needing recovery (DB_RUNRECOVERY).
What could be the cause?</a></li>
<li><a href="#bdb-recovery">Every time I try to access
my repository, the process just hangs. Is my repository
corrupt?</a></li>
<li><a href="#bdb-cannot-allocate-memory">My repository keeps giving
errors saying "Cannot allocate memory". What should I do?</a></li>
<li><a href="#wedged-wc">Every time I try to run a svn
command, it says my working copy is locked. Is my working copy
corrupt?</a></li>
<li><a href="#wc-out-of-date">I'm trying to commit, but Subversion says my
working copy is out of date?</a></li>
<li><a href="#obstructed-add">I've contributed a patch to a project and the patch added a new file.
Now <tt>svn update</tt> does not work.</a></li>
<li><a href="#unrecognized-url-error">I just built the distribution
binary, and when I try to check out Subversion, I get an error
about an "Unrecognized URL scheme." What's up with that?</a></li>
<li><a href="#db-recover">I'm getting errors finding or opening a repository,
but I know my repository URL is correct. What's wrong?</a></li>
<li><a href="#configure-sed-error">When I run `<tt>configure</tt>', I
get errors <tt>subs-1.sed&nbsp;line&nbsp;38:&nbsp;Unterminated&nbsp;`s'&nbsp;command</tt>. What's wrong?</a></li>
<li><a href="#windows-msvc-build">I'm having trouble building
Subversion under Windows with MSVC++ 6.0. What should I do?</a></li>
<li><a href="#windows-drive-letter">How can I specify a Windows drive letter in
a <tt>file:</tt> URL?</a></li>
<li><a href="#write-over-dav">I'm having trouble doing write
operations to a Subversion repository over a network.</a></li>
<li><a href="#vs-asp-net">VS.NET/ASP.NET seems to have a problem with
the ".svn" directory name. What should I do?</a></li>
<li><a href="#windows-xp-server">Under Windows XP, the Subversion
server sometimes seems to send out corrupted data. Can this really be
happening?</a></li>
<li><a href="#net-trace">What is the best method of doing a network
trace of the conversation between a Subversion client and server?</a></li>
<li><a href="#revert">Why does the <tt>svn revert</tt> require an
explicit target? Why is it not recursive by default? These
behaviors differ from almost all the other subcommands.</a></li>
<li><a href="#db3db4">When I start Apache, mod_dav_svn complains about
a "bad database version", that it found db-3.X, rather than
db-4.X.</a></li>
<li><a href="#redhat-db">I'm getting "Function not implemented" errors on
Red Hat 9, and nothing works. How do I fix this?</a></li>
<li><a href="#no-author">Why does SVN log say "(no author)" for files
committed or imported via Apache (ra_dav)?</a></li>
<li><a href="#windows-access-denied">I'm getting occasional "Access Denied"
errors on Windows. They seem to happen at random. Why?</a></li>
<li><a href="#freebsd-hang">On FreeBSD, certain operations (especially
svnadmin create) sometimes hang. Why?</a></li>
<li><a href="#http-301-error">I can see my repository in a web browser, but
'svn checkout' gives me an error about "301 Moved Permanently".
What's wrong?</a></li>
<li><a href="#no-copy-history">I'm trying to look at an old version of my
file, but svn says something about "path not found". What's going
on?</a></li>
<li><a href="#digest-auth">Why doesn't HTTP Digest auth work?</a></li>
<li><a href="#xlc-compile">Compiling with xlc on AIX, I get compilation
errors. What's wrong?</a></li>
<li><a href="#nonrecursive-checkout">I checked out a directory
non-recursively (with -N), and now I want to make certain
subdirectories "appear". But <tt>svn up subdir</tt> doesn't
work.</a></li>
<li><a href="#mod_dav_svn-win32">I am trying to use mod_dav_svn
with Apache on Win32 and I'm getting an error saying that the
module cannot be found, yet the mod_dav_svn.so file is right
there in <tt>\Apache\modules.</tt></a></li>
<li><a href="#hook-debugging">Why aren't my repository hooks working?</a></li>
<li><a href="#diff-cmd">Why does my --diff-cmd complain about '-u'?
I tried to override it with --extensions, but it's not working.</a></li>
<li><a href="#plaintext-passwords">Ahhh! I just discovered that my
Subversion client is caching passwords in plain-text on disk!
AHHH!</a></li>
<li><a href="#bdb41-tabletype-bug">I'm getting the error "svn: bdb: call
implies an access method which is inconsistent with previous
calls". How do I fix this?</a></li>
<li><a href="#hotcopy-large-repos">I can't hotbackup my repository, svnadmin
fails on files larger than 2Gb!</a></li>
<li><a href="#hidden-log">I cannot see the log entry for the file
I just committed. Why?</a></li>
<li><a href="#bdb43-upgrade">After upgrading to Berkeley DB
4.3 or later, I'm seeing repository errors.</a></li>
<li><a href="#tiger-apr-0.9.6">Why do I get occasional, seemingly
inconsistent errors when checking out over http:// from a repository
running on MacOS X 10.4 (Tiger)?</a></li>
<li><a href="#debian-libtool">I can't build Subversion from working
copy source on Debian GNU/Linux; I get errors at the final link
stage. What's wrong?</a></li>
<li><a href="#freebsd-listen-host">I'm using FreeBSD, and I've started
svnserve, but it doesn't seem to be listening on port 3690.</a></li>
<li><a href="#already-under-version-control">I can't add a directory
because Subversion says it's "already under version control".</a></li>
<li><a href="#slow-private-svnserve">Accessing non-public repositories
via svnserve is really slow sometimes.</a></li>
<li><a href="#ssl-negotiation-error">When performing Subversion
operations involving a lot of data over SSL, I get the error
<tt>SSL negotiation failed: SSL error: decryption failed or bad
record mac</tt>.</a></li>
<li><a href="#broken-subclipse">I get an error that says "This client is too
old".</a></li>
<li><a href="#switch-problems">Why doesn't <tt>svn switch</tt> work
in some cases?</a></li>
<li><a href="#long-paths">In Windows, when doing an update with the
command-line client, I get an error saying "The
system cannot find the path specified" and suggesting that my
working copy might be corrupt. But I can update with TortoiseSVN
just fine. What's going on?</a></li>
<li><a href="#working-copy-format-change">I got an error saying "This
client is too old to work with working copy '...' ". How can I
fix it without upgrading Subversion?</a></li>
</ul>
<h4>Developer questions:</h4>
<ul>
<li><a href="#ramdisk-tests">How do I run the regression tests in a
RAM disk?</a></li>
<li><a href="#dynamic-exe-debugging">How do I run a debugger on
dynamic Subversion binaries without having to install
them?</a></li>
<li><a href="#avoiding-compiler-inlining">How do I run a debugger on
Subversion binaries without compiler inlining obfuscating the
source?</a></li>
</ul>
<h4>References:</h4>
<ul>
<li><a href="#http-methods">What are all the HTTP methods Subversion
uses?</a></li>
<li><a href="#bikeshed">What's a 'bikeshed'?</a></li>
<li><a href="#pronounce">How do you pronounce "Subversion"?</a></li>
<li><a href="#baton">What's a 'baton'?</a></li>
<li><a href="#def-wedged-repository">What do you mean when you say that
repository is 'wedged'?</a></li>
</ul>
</div>
<hr/>
<div class="h2" id="general-questions" title="general-questions">
<h2>General questions:</h2>
<div class="h3" id="why" title="why">
<h3>Why does this project exist?</h3>
<p>To take over the CVS user base. Specifically, we're writing a new
version control system that is very similar to CVS, but fixes many
things that are broken. See our front page.</p>
</div>
<div class="h3" id="collab" title="collab">
<h3>Is Subversion proprietary? I heard that it
belongs to CollabNet.</h3>
<p>No, Subversion is open source / free software. CollabNet pays the
salaries of several full-time developers, and holds the copyright on
the code, but that copyright is <a
href="http://subversion.tigris.org/license-1.html">an
Apache/BSD-style license</a>
which is fully compliant with the <a
href="http://www.debian.org/social_contract#guidelines">Debian Free
Software Guidelines</a>. In other words, you are free to download,
modify, and redistribute Subversion as you please; no permission from
CollabNet or anyone else is required.</p>
</div>
<div class="h3" id="stable" title="stable">
<h3>Is Subversion stable enough for me to use for my
own projects?</h3>
<p>Yes, absolutely. It's ready for prime-time production.</p>
<p>Subversion has been in development since 2000, and became
self-hosting after one year. A year later when we declared "alpha",
Subversion was already being used by dozens of private developers and
shops for real work. After that, it was two more years of bugfixing
and stabilization until we reached 1.0. Most other projects probably
would have called the product "1.0" much earlier, but we deliberately
decided to delay that label as long as possible. We were aware that
many people were waiting for a 1.0 before using Subversion, and had
very specific expectations about the meaning of that label. So we
stuck to that same standard.</p>
</div>
<div class="h3" id="interop" title="interop">
<h3>What is Subversion's client/server
interoperability policy?</h3>
<p>The client and server are designed to work as long as they aren't
more than one major release version apart. For example, any 1.X
client will work with a 1.Y server. However, if the client and
server versions don't match, certain features may not be available.</p>
<p>See the client/server interoperability policy is documented in the
"Compatibility" section of the <a href="hacking.html">Hacker's Guide
to Subversion</a>.</p>
</div>
<div class="h3" id="portability" title="portability">
<h3>What operating systems does Subversion run
on?</h3>
<p>All modern flavors of Unix, Win32, BeOS, OS/2, MacOS X.</p>
<p>Subversion is written in ANSI C and uses APR, the <a
href="http://apr.apache.org">Apache Portable Runtime</a> library, as a
portability layer. The Subversion client will run anywhere APR runs,
which is most places. The Subversion server (i.e., the repository
side) is the same, except that it will not host a Berkeley DB repository
on Win9x platforms (Win95/Win98/WinME), because Berkeley DB has
shared-memory segment problems on Win9x. FSFS repositories
(introduced in version 1.1) do not have this restriction; however, due
to a limitation in Win9x's file-locking support, they also don't work
in Win9x.</p>
<p>To reiterate, the Subversion client can be run on any platform
where APR runs. The Subversion server can also be run on any
platform where APR runs, but cannot host a repository on
Win95/Win98/WinMe.</p>
</div>
<div class="h3" id="filesystem" title="filesystem">
<h3>What's all this about a new filesystem? Is
it like ext2?</h3>
<p>No. The "Subversion Filesystem" is not a kernel-level filesystem
that one would install in an operating system. Instead, it is
Subversion's repository interface, which is a "versioned filesystem"
in the sense that it stores a directory tree whose state is remembered
from revision to revision. Writing programs to access the repository
is similar to writing programs that use other filesystem APIs. The
main difference is that this particular filesystem doesn't lose data
when written to; old tree states can be retrieved as easily the most
recent state.</p>
</div>
<div class="h3" id="server-requirements" title="server-requirements">
<h3>What kind of hardware do I need to run a Subversion server?</h3>
<p>Server requirements depend on many factors, such as number of
users, frequency of commits and other server related operations,
repository size, and the load generated by custom repository hooks.
When using Apache, it is likely that Apache itself will be the biggest
factor in memory usage. See
<a href="http://subversion.tigris.org/servlets/BrowseList?list=users&amp;by=thread&amp;from=330941"
>this discussion</a> on the mailing list for some concrete
answers.</p>
<p>Remember to take in account other applications running on the same
server; for example, repository browsers use resources too,
independently of Subversion itself.</p>
<p>In general, you can expect to need much less server memory than you
would for comparable CVS repositories.</p>
</div>
<div class="h3" id="apache-extension" title="apache-extension">
<h3>I heard that Subversion is an Apache
extension? What does it use for servers?</h3>
<p>No. Subversion is a set of libraries. It comes with a
command-line client that uses them. There are two different
Subversion server processes: either <b>svnserve</b>, which is small
standalone program similar to cvs pserver, or Apache <b>httpd-2.0</b>
using a special <b>mod_dav_svn</b> module. <b>svnserve</b> speaks a
custom protocol, while <b>mod_dav_svn</b> uses WebDAV as its network
protocol. See <a
href="http://svnbook.red-bean.com/html-chunk/ch06.html">chapter 6</a>
in the Subversion book to learn more.</p>
</div>
<div class="h3" id="need-apache" title="need-apache">
<h3>Does this mean I have to set up Apache to
use Subversion?</h3>
<p>The short answer: no.</p>
<p>The long answer: if you just want to access a repository, then you
only need to build a Subversion client. If you want to <b>host</b> a
networked repository, then you need to set up either Apache2 or an
"svnserve" server.</p>
<p>For more details about setting up a network accessible Subversion
server, see <a
href="http://svnbook.red-bean.com/html-chunk/ch06.html">chapter 6</a>
in the Subversion book.</p>
</div>
<div class="h3" id="multiple-apachim" title="multiple-apachim">
<h3>I run Apache 1.x right now, and can't
switch to Apache 2.0 just to serve Subversion repositories.
Does that mean I can't run a Subversion server?</h3>
<p>No, you can run <b>svnserve</b> as a Subversion server. It works
extremely well.</p>
<p>If you want WebDAV and all the other "goodies" that come with the
Apache server, then yes, you'll need Apache 2.0. It's always an
option to run Apache 2.0 on a different port while continuing to run
Apache 1.x on port 80. Different versions of Apache can happily
coexist on the same machine. Just change the <tt>Listen</tt>
directive in httpd.conf from "<tt>Listen&nbsp;80</tt>" to
"<tt>Listen&nbsp;8080</tt>" or whatever port number you want, and make
sure to specify that port when you publish your repository URL (e.g.,
<tt>http://svn.mydomain.com:8080/repos/blah/trunk/</tt>).</p>
</div>
<div class="h3" id="feature-x" title="feature-x">
<h3>Why don't you do X, just like SCM system Y?</h3>
<p>We aren't attempting to break new ground in SCM systems, nor are we
attempting to imitate all the best features of every SCM system out
there. We're trying to replace CVS. See the first question.</p>
</div>
<div class="h3" id="globalrev" title="globalrev">
<h3>Why does the entire repository share the
same revision number? I want each of my projects to have their
own revision numbers.</h3>
<p>
The global revision number attached to the repository as a whole is
meaningless from a user's perspective. It's an internal mechanism that
accomplishes the goal of the underlying schema design. It just so
happens to be exposed so that the user's interface can sometimes be a
little more convenient than always having to type obnoxiously long
date/time strings.
</p>
<p>
The revision number is only relevant to the repository, and user
convenience. It has <b>no</b> impact on any other factor of what you
store in the repository. Repository revision number bumps aren't
nearly useful enough to be an accurate indication of the real rate of
change of a given code base. There are other more complicated ways to
get a much better picture of a code-base's rate of change.
</p>
</div>
<div class="h3" id="changesets" title="changesets">
<h3>Does Subversion have Changesets?</h3>
<p>The question is a bit loaded, because everyone seems to have a
slightly different definition of "changeset", or a least a slightly
different expectation of what it means for a version control system to
have "changeset features".</p>
<p>For the purposes of this discussion, here's a simple definition of
changeset: it's a collection of changes with a unique name. The
changes might include textual edits to file contents, modifications to
tree structure, or tweaks to metadata. In more common speak, a
changeset is just a patch with a name you can refer to.</p>
<p>Subversion manages versioned trees as first order objects (the
repository is an array of trees), and the changesets are things that
are derived (by comparing adjacent trees.) Systems like Arch or
Bitkeeper are built the other way around: they're designed to manage
changesets as first order objects (the repository is a bag of
patches), and trees are derived by composing sets of patches
together.</p>
<p>Neither philosophy is better in absolute terms: the debate goes
back at least 30 years. The two designs are better or worse for
different types of software development. We're not going to discuss
that here. Instead, here's an explanation of what you can do with
Subversion.</p>
<p>In Subversion, a global revision number 'N' names a tree in the
repository: it's the way the repository looked after the Nth commit.
It's also the name of an implicit changeset: if you compare tree N
with tree N-1, you can derive the exact patch that was committed.</p>
<p>For this reason, it's easy to think of "revision N" as not just a
tree, but a changeset as well. If you use an issue tracker to manage
bugs, you can use the revision numbers to refer to particular patches
that fix bugs -- for example, "this issue was fixed by revision 9238."
Somebody can then run 'svn log -r9238' to read about the exact
changeset which fixed the bug, and run 'svn diff -r9237:9238' to see
the patch itself. And svn's merge command also uses revision numbers.
You can merge specific changesets from one branch to another by naming
them in the merge arguments: 'svn merge -r9237:9238 branchURL' would
merge changeset #9238 into your working copy.</p>
<p>This is nowhere near as complicated as a system built around
changesets as primary objects, but it's still a vast convenience over
CVS.</p>
</div>
<div class="h3" id="release" title="release">
<h3>When's the next release?</h3>
<p>See our status page, <a
href="http://subversion.tigris.org/project_status.html">
http://subversion.tigris.org/project_status.html</a>.</p>
</div>
<div class="h3" id="symlinks" title="symlinks">
<h3>Does Subversion support symlinks?</h3>
<p>Subversion 1.1 (and later) has the ability to put a symlink under
version control, via the usual <tt>svn add</tt> command.</p>
<p>Details: the Subversion repository has no internal concept of a
symlink. It stores a "versioned symlink" as an ordinary file with an
'svn:special' property attached. The svn client (on unix) sees the
property and translates the file into a symlink in the working copy.
Win32 has no symlinks, so a win32 client won't do any such
translation: the object appears as a normal file.</p>
</div>
<div class="h3" id="logo" title="logo">
<h3>I need a high resolution version of the Subversion logo,
where can I get it?</h3>
<p>Vectorized versions of the Subversion logo are available in the <a
href="http://svn.collab.net/repos/svn/trunk/www">logo directory of the www
tree</a> of the <a href="http://svn.collab.net/repos/svn/trunk">Subversion
repository</a>.</p>
<p>Specifically, an <a
href="http://svn.collab.net/repos/svn/trunk/www/logo/subversion_logo.eps">EPS
version</a>, as well as an <a
href="http://svn.collab.net/repos/svn/trunk/www/logo/subversion_logo.ai">Adobe
Illustrator document</a> are available.</p>
</div>
<div class="h3" id="more-information" title="more-information">
<h3>I have other questions. Where can I get more information?</h3>
<p>If you don't find an answer after browsing this FAQ, there are several
other resources available:</p>
<ul>
<li><a href="http://svnbook.red-bean.com">The Subversion Book</a></li>
<li><a href="http://subversion.tigris.org/servlets/ProjectMailingListList">The
Subversion Users mailing list</a> (<a
href="mailto:users@subversion.tigris.org"
>users@subversion.tigris.org</a>)
&mdash; note that the list is <a href="#moderation">moderated</a>, so
there may be a delay before your post shows up</li>
<li><a href="http://svn.haxx.se/users/">The Subversion Users list
archives</a></li>
<li>IRC on channel #svn on irc.freenode.net</li>
<li><a href="http://www.svnforum.org/">svnforum.org</a>, an unofficial
web-based forum with approximately the same target audience as the mailing
list</li>
</ul>
</div>
<div class="h3" id="moderation" title="moderation">
<h3>Why isn't my post showing up on the mailing list?</h3>
<p>Our mailing lists are moderated to prevent spam from getting
through, so your first post to any list may be delayed, until the
moderator has a chance to let it through. Once that post is allowed
through, all subsequent posts from the same address are automatically
approved, so you should experience no more delay. Of course, if your
sending address changes, then you'll have to go through moderation
again.</p>
</div>
</div>
<div class="h2" id="how-to" title="how-to">
<h2>How-to:</h2>
<p/>
<div class="h3" id="co-svn" title="co-svn">
<h3>How do I check out the Subversion code?</h3>
<p>Use the Subversion client:</p>
<pre>
$ svn co http://svn.collab.net/repos/svn/trunk subversion
</pre>
<p>That will check out a copy of the Subversion source tree into a
directory named subversion on your local machine.</p>
</div>
<div class="h3" id="repository" title="repository">
<h3>How do I create a repository? How do I
import data into it?</h3>
<p>See <a
href="http://svn.collab.net/repos/svn/trunk/README">
http://svn.collab.net/repos/svn/trunk/README</a>; specifically, look
at section IV, the "Quickstart Guide".</p>
<p>For even more detail, read chapter 5 in <a
href="http://svnbook.red-bean.com">The Subversion Book</a>.</p>
</div>
<div class="h3" id="cvs2svn" title="cvs2svn">
<h3>How do I convert an existing CVS repository
into a Subversion repository?</h3>
<p>Members of the Subversion development community created and
maintain a tool called cvs2svn. You can find it at <a
href="http://cvs2svn.tigris.org/">http://cvs2svn.tigris.org/</a>. Be
sure to read the <a
href="http://cvs2svn.tigris.org/cvs2svn.html">cvs2svn documentation</a>.
</p>
<p>If cvs2svn.py does not work for you, (e.g. your repository
causes it to crash, or it doesn't deal with branches and tags
quite how you would like), there are at least two other
conversion utilities you can try. These have different features
(and possibly different bugs):</p>
<ul>
<li>One based on <a
href="http://public.perforce.com/public/revml/index.html">VCP</a>
written by Chia-liang Kao can be found on <a
href="http://search.cpan.org/perldoc?VCP::Dest::svk">CPAN</a>.</li>
<li>refinecvs written by Lev Serebryakov is at <a
href="http://lev.serebryakov.spb.ru/refinecvs/"
>http://lev.serebryakov.spb.ru/refinecvs/</a>.</li>
</ul>
<p>See also the <a href="links.html">Subversion links</a>
page.</p>
</div>
<div class="h3" id="proxy" title="proxy">
<h3>What if I'm behind a proxy?</h3>
<p>The Subversion client can go through a proxy, if you configure it
to do so. First, edit your "servers" configuration file
to indicate which proxy to use. The files location depends on your
operating system. On Linux or Unix it is located in the directory
"~/.subversion". On Windows it is in "%APPDATA%\Subversion". (Try
"echo %APPDATA%", note this is a hidden directory.)</p>
<p>There are comments in the file explaining what to do. If you don't
have that file, get the latest Subversion client and run any command;
this will cause the configuration directory and template files to be
created.</p>
<p>Next, you need to make sure the proxy server itself supports all
the HTTP methods Subversion uses. Some proxy servers do not support
these methods by default: PROPFIND, REPORT, MERGE, MKACTIVITY,
CHECKOUT. In general, solving this depends on the particular proxy
software. For Squid, the config option is</p>
<pre>
# TAG: extension_methods
# Squid only knows about standardized HTTP request methods.
# You can add up to 20 additional "extension" methods here.
#
#Default:
# none
extension_methods REPORT MERGE MKACTIVITY CHECKOUT
</pre>
<p>(Squid 2.4 and later already knows about PROPFIND.)</p>
<p>See also "<a href="#http-methods">What are all the HTTP methods
Subversion uses?</a>" for advice on additional HTTP methods to allow
through your proxy.</p>
<p>If it's difficult or impossible to get the proxy to allow
Subversion traffic, but you want to check out the Subversion sources,
you may be able to go around the proxy. Some proxies that filter port
80 nevertheless allow anything on port 81. For this reason, the
<tt>svn.collab.net</tt> repository server listens on port 81 as well
as on port 80. Try:</p>
<pre>
svn checkout http://svn.collab.net:81/repos/svn/trunk subversion
</pre>
<p>and maybe the proxy will let you through. Another strategy is to
attempt the checkout over SSL, which many proxies allow:</p>
<pre>
svn checkout https://svn.collab.net/repos/svn/trunk subversion
</pre>
<p>Of course, your svn client will have to have been built with ssl
support; just pass <tt>--with-ssl</tt> to Subversion's
<tt>./configure</tt> script. You can check to see whether the 'https'
scheme is supported by running <tt>svn --version</tt>.</p>
</div>
<div class="h3" id="paranoid" title="paranoid">
<h3>My admins don't want me to have a HTTP server for
Subversion. What can I do if I still want remote usage?</h3>
<p>A simple option is to use the <b>svnserve</b> server instead of
Apache. See <a
href="http://svnbook.red-bean.com/html-chunk/ch06.html">chapter 6</a>
in the Subversion book for details.</p>
<p>However, if your admins don't want you to run Apache, it's very
likely they don't want you to run a custom server process on port 3690
either! So the rest of this answer assumes that your admins
<i>are</i> okay with you using an existing SSH infrastructure.</p>
<p>If you previously used CVS, you may have used SSH to login to the
CVS server. The ra_svn Subversion access method is the equivalent way
of doing this with Subversion. Just use the "svn+ssh" prefix to your
Subversion repository URL.</p>
<pre>
$ svn checkout svn+ssh://your.domain.com/full/path/to/repository
</pre>
<p>This makes your SSH program launch a private 'svnserve' process on
the remote box, which accesses the repository as your UID and tunnels
the information back over the encrypted link.</p>
<p>However, another solution that can be used instead is to leverage
SSH port forwarding to connect to the protected server via ra_dav.
You would connect via SSH to a machine behind your firewall that can
access your Subversion server. Note that this SSH server does
<b>not</b> have to be the same as where Subversion is installed. It
can be, but it doesn't have to be.</p>
<p>Then, you create a local port forward that connects to the HTTP
server that houses your Subversion repository. You would then
'connect' to the Subversion repository via this local port. Then,
the request will be sent 'tunneled' via SSH server to your Subversion
server.</p>
<p>An example: a Subversion ra_dav setup is behind your company firewall
at 10.1.1.50 (call it svn-server.example.com). Your company allows SSH
access via publicly accessible ssh-server.example.com. Internally, you
can access the Subversion repository via
http://svn-server.example.com/repos/ours.</p>
<p><i>Example</i>: client connecting to ssh-server with port-forwarding
and checking out via the port forward</p>
<pre>
% ssh -L 8888:svn-server.example.com:80 me@ssh-server.example.com
% svn checkout http://localhost:8888/repos/ours
</pre>
<p>Note that your svn-server.example.com could also have its httpd
instance running on an unprivileged port by a non-trusted user. This
will allow your Subversion server not to require root access.</p>
<!-- Can you use svn switch to switch your WC between your internal and
external Subversion server? I think so. -->
<p>Joe Orton notes</p>
<pre>
The server is sensitive to the hostname used in the Destination header
in MOVE and COPY requests, so you have to be a little careful here - a
"ServerAlias localhost" may be required to get this working properly.
</pre>
<p>Some links on SSH port forwarding</p>
<ul>
<li><a href="http://www.onlamp.com/pub/a/onlamp/excerpt/ssh_11/index3.html"
>http://www.onlamp.com/pub/a/onlamp/excerpt/ssh_11/index3.html</a></li>
<li><a href="http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/"
>http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/</a></li>
<li><a href="http://www.zip.com.au/~roca/ttssh.html">TTSSH: A Win32 SSH client capable of port forwarding</a></li>
</ul>
</div>
<div class="h3" id="multi-proj" title="multi-proj">
<h3>How do I manage several different projects under Subversion?</h3>
<p>It depends upon the projects involved. If the projects are
related, and are likely to share data, then it's best to create one
repository with several subdirectories like this:</p>
<pre>
$ svnadmin create /repo/svn
$ svn mkdir file:///repo/svn/projA
$ svn mkdir file:///repo/svn/projB
$ svn mkdir file:///repo/svn/projC
</pre>
<p>If the projects are completely unrelated, and not likely to share data
between them, then it's probably best to create separate and unrelated
repositories.</p>
<pre>
$ mkdir /repo/svn
$ svnadmin create /repo/svn/projA
$ svnadmin create /repo/svn/projB
$ svnadmin create /repo/svn/projC
</pre>
<p>
The difference between these two approaches is this (as explained by
Ben Collins-Sussman &lt;sussman@collab.net&gt;):</p>
<ul>
<li>
In the first case, code can easily be copied or moved around
between projects, and the history is preserved. ('svn cp/mv'
currently only works within a single repository.)
</li>
<li>
Because revision numbers are repository-wide, a commit to any
project in the first case causes a global revision bump. So it
might seem a bit odd if somebody has 'projB' checked out, notices
that 10 revisions have happened, but projB hasn't changed at
all. Not a big deal, really. Just a little weird at first.
This used to happen to svn everytime people committed to
rapidsvn, when rapidsvn was in the same repository. :-)
</li>
<li>
The second case might be easier to secure; it's easier to insulate
projects from each other (in terms of users and permissions)
using Apache's access control. In the 1st case, you'll need a
fancy hook script in the repository that distinguishes projects
("is this user allowed to commit to this particular subdir?") Of
course, we already have such a script, ready for you to use.
</li>
</ul>
</div>
<div class="h3" id="multi-merge" title="multi-merge">
<h3>How do I merge two completely separate repositories?</h3>
<p>If you don't care about retaining all the history of one of the
repositories, you can just create a new directory under one project's
repository, then import the other.</p>
<p>If you care about retaining the history of both, then you can use
'svnadmin dump' to dump one repository, and 'svnadmin load' to load it into
the other repository. The revision numbers will be off, but you'll
still have the history.</p>
<p>Peter Davis &lt;peter@pdavis.cx&gt; also explains a method using svn's
equivalent to CVS modules:</p>
<blockquote>
<p>As long as the merging takes place in separate directory
trees, you can use svn's version of CVS modules.</p>
<p>Set the <em>svn:externals</em> property on a directory to checkout
directories from other repositories whenever the original
directory is checked out. The repository remains separate,
but in the working copy it appears that they have been merged.
If you commit to the imported directory, it will affect the
external repository.</p>
<p>The merge isn't completely clean: the import only affects
working copies, so you won't be able to use a URL in the first
repository to access modules imported from the second. They
remain separate URLs.</p>
</blockquote>
</div>
<div class="h3" id="nfs" title="nfs">
<h3>Should I store my repository / working copy on a NFS
server?</h3>
<p>If you are using a repository with the Berkeley DB back end
(default for repositories created with Subversion 1.0 and 1.1, not the
default thereafter), we recommend <i>not</i> storing the repository on
a remote filesystem (for example, NFS). While Berkeley DB databases
and log files can be stored on remote filesystems, the Berkeley DB
shared region files cannot be stored on a remote filesystem, so the
repository may be safely accessed by only a single filesystem client,
and not all Subversion functionality will be available to even that
one client.</p>
<p>If you are using the <a
href="http://svn.collab.net/repos/svn/trunk/notes/fsfs">FSFS</a>
repository back end, then storing the repository on a modern NFS
server (i.e., one that supports locking) should be fine.</p>
<p>Working copies can be stored on NFS (one common scenario is when
your home directory is on a NFS server). On Linux NFS servers, due to
the volume of renames used internally in Subversion when checking out
files, some users have reported that 'subtree checking' should be
disabled (it's enabled by default). Please see <a
href="http://nfs.sourceforge.net/nfs-howto/server.html" >NFS Howto
Server Guide</a> and <b>exports(5)</b> for more information on how to
disable subtree checking.</p>
<p>We've had at least one report of working copies getting wedged
after being accessed via SMB. The server in question was running a
rather old version of Samba (2.2.7a). The problem didn't recur with a
newer Samba (3.0.6).</p>
</div>
<div class="h3" id="bdblogs" title="bdblogs">
<h3>Why is my repository taking up so much disk space?</h3>
<p>The repository stores all your data in a Berkeley DB "environment"
in the repos/db/ subdirectory. The environment contains a collection
of tables and bunch of logfiles (log.*). Berkeley DB journals all
changes made to the tables, so that the tables can be recovered to a
consistent state in case of interruptions (<a
href="#bdb-recovery">more info</a>).</p>
<p>The logfiles will grow forever, eating up disk space, unless you,
(as the repository administrator) do something about it. At any given
moment, Berkeley DB is only using a few logfiles actively (see <a
href="http://subversion.tigris.org/servlets/ReadMsg?list=users&amp;msgNo=15194"
>this post</a> and its associated thread); the rest can be safely
deleted. If you keep all the logfiles around forever, then in theory
Berkeley DB can replay every change to your repository from the day it
was born. But in practice, if you're making backups, it's probably
not worth the cost in disk space.</p>
<p>Use <code>svnadmin</code> to see
which log files can be deleted. You may want a cron job to do this.</p>
<pre>
$ svnadmin list-unused-dblogs /repos
/repos/db/log.000003
/repos/db/log.000004
[...]
$ svnadmin list-unused-dblogs /repos | xargs rm
# disk space reclaimed!
</pre>
<p>You could instead use Berkeley DB's <code>db_archive</code> command:</p>
<pre>
$ db_archive -a -h /repos/db | xargs rm
# disk space reclaimed!
</pre>
<p>See also <code>svnadmin hotcopy</code> or <code>hotbackup.py</code>.</p>
<p><strong>Note:</strong> If you use Berkeley DB 4.2, Subversion will
create new repositories with automatic log file removal enabled. You
can change this by passing the <code>--bdb-log-keep</code> option to
<code>svnadmin create</code>. Refer to the section about the <a
href="http://www.oracle.com/technology/documentation/berkeley-db/db/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE">
<code>DB_LOG_AUTOREMOVE</code></a> flag in the Berkeley DB manual.</p>
</div>
<div class="h3" id="reposperms" title="reposperms">
<h3>How do I set repository
permissions correctly?</h3>
<p>Try to have as <em>few</em> users access the repository as
possible. For example, run apache or 'svnserve -d' as a specific
user, and make the repository wholly owned by that user. Don't allow
any other users to access the repository via <tt>file:///</tt> urls,
and be sure to run 'svnlook' and 'svnadmin' only as the user which
owns the repository.</p>
<p>If your clients are accessing via <tt>file:///</tt> or
<tt>svn+ssh://</tt>, then there's no way to avoid access by multiple
users. In that case, read <a
href="http://svnbook.red-bean.com/html-chunk/ch06s05.html">the last
section in chapter 6</a>, and pay particular attention to the
"checklist" sidebar at the bottom. It outlines a number of steps to
make this scenario safer.</p>
<b>Note for SELinux / Fedora Core 3+ / Red Hat Enterprise users:</b>
<p>In addition to regular Unix permissions, under SELinux every file,
directory, process, etc. has a 'security context'. When a process
attempts to access a file, besides checking the Unix permissions the
system also checks to see if the security context of the process is
compatible with the security context of the file.</p>
<p>Fedora Core 3, among other systems, comes with SELinux installed by
default, configured so that Apache runs in a fairly restricted
security context. To run Subversion under Apache, you have to set the
security context of the repository to allow Apache access (or turn off
the restrictions on Apache, if you think all this is overkill). The
<tt>chcon</tt> command is used to set the security context of files
(similarly to how the <tt>chmod</tt> sets the traditional Unix
permissions). For example, one user had to issue this command</p>
<pre> $ chcon -R -h -t httpd_sys_content_t <i>PATH_TO_REPOSITORY</i></pre>
<p>to set the security context to be able to successfully
access the repository.</p>
</div>
<div class="h3" id="readonly" title="readonly">
<h3>Why do read-only operations still need repository
write access?</h3>
<p>Certain client operations are "read-only", like checkouts and
updates. From an access-control standpoint, Apache treats them as
such. But libsvn_fs (the repository filesystem API) still has to
write temporary data in order to produce tree-deltas. So the process
accessing the repository always requires both read <em>and</em> write
access to the Berkeley DB files in order to function.</p>
<p>In particular, the repository responds to many "read-only"
operations by comparing two trees. One tree is the usually the HEAD
revision, and the other is often a temporary transaction-tree -- thus
the need for write access.</p>
<p>This limitation only applies to the Berkeley DB backend; the <a
href="http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A">FSFS
backend</a> does not exhibit this behaviour.</p>
</div>
<div class="h3" id="removal" title="removal">
<h3>
How do I completely remove a file from the repository's history?
</h3>
<p>There are special cases where you might want to destroy all
evidence of a file or commit. (Perhaps somebody accidentally committed
a confidential document.) This isn't so easy, because Subversion is
deliberately designed to never lose information. Revisions are
immutable trees which build upon one another. Removing a revision from
history would cause a domino effect, creating chaos in all subsequent
revisions and possibly invalidating all working copies.</p>
<p>The project has plans, however, to someday implement an <b>svnadmin
obliterate</b> command which would accomplish the task of permanently
deleting information. (See <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=516">issue
516</a>.)</p>
<p>In the meantime, your only recourse is to <b>svnadmin dump</b> your
repository, then pipe the dumpfile through <b>svndumpfilter</b>
(excluding the bad path) into an <b>svnadmin load</b> command. See <a
href="http://svnbook.red-bean.com/html-chunk/ch05.html">chapter 5</a>
of the Subversion book for details about this.</p>
</div>
<div class="h3" id="change-log-msg" title="change-log-msg">
<h3>
How do I change the log message for a revision after it's been committed?
</h3>
<p>Log messages are kept in the repository as properties attached to each
revision. By default, the log message property (<em>svn:log</em>) cannot be
edited once it is committed. That is because changes to <a
href="http://svnbook.red-bean.com/svnbook/ch05.html#svn-ch-5-sect-1.2">revision
properties</a> (of which <em>svn:log</em> is one) cause the property's
previous value to be permanently discarded, and Subversion tries to prevent
you from doing this accidentally. However, there are a couple of ways to get
Subversion to change a revision property.</p>
<p>The first way is for the repository administrator to enable revision
property modifications. This is done by creating a hook called
"pre-revprop-change" (see <a
href="http://svnbook.red-bean.com/svnbook/ch05s02.html#svn-ch-5-sect-2.1">this
section</a> in the Subversion book for more details about how to do this).
The "pre-revprop-change" hook has access to the old log message before it is
changed, so it can preserve it in some way (for example, by sending an email).
Once revision property modifications are enabled, you can change a revision's
log message by passing the --revprop switch to <b>svn propedit</b> or <b>svn
propset</b>, like either one of these:</p>
<pre>
$ svn propedit -r N --revprop svn:log URL
$ svn propset -r N --revprop svn:log "new log message" URL
</pre>
<p>where N is the revision number whose log message you wish to change, and
URL is the location of the repository. If you run this command from within a
working copy, you can leave off the URL.</p>
<p>The second way of changing a log message is to use <b>svnadmin setlog</b>.
This must be done by referring to the repository's location on the filesystem.
You cannot modify a remote repository using this command.</p>
<pre>
$ svnadmin setlog REPOS_PATH -r N FILE
</pre>
<p>where REPOS_PATH is the repository location, N is the revision number whose
log message you wish to change, and FILE is a file containing the new log
message. If the "pre-revprop-change" hook is not in place (or you want to
bypass the hook script for some reason), you can also use the --bypass-hooks
option. However, if you decide to use this option, be very careful. You may
be bypassing such things as email notifications of the change, or backup
systems that keep track of revision properties.</p>
</div>
<div class="h3" id="patch" title="patch">
<h3>How do I submit a patch for Subversion?</h3>
<p>FIRST, read the <a href="hacking.html">Hacker's Guide to
Subversion</a>.</p>
<p>Once you've digested that, send a mail to the dev list with the
word [PATCH] and a one-line description in the subject, and include
the patch inline in your mail (unless your MUA munges it up
totally). Then a committer will pick it up, apply it (making any
formatting or content changes necessary), and check it in.</p>
<p>The basic process looks like this:</p>
<blockquote><pre>
$ svn co http://svn.collab.net/repos/svn/trunk subversion
$ cd subversion/www
[ make changes to faq.html ]
$ svn diff faq.html &gt; /tmp/foo
$ Mail -s "[PATCH] FAQ updates" &lt; /tmp/foo
</pre></blockquote>
<p>Of course, the email you send should contain a nice long
explanation about what the patch does, as per the
<a href="hacking.html">Hacker's Guide to Subversion</a>, but you
already know that, since you read and completely understood
it <em>before</em> actually hacking the code, right? :)</p>
</div>
<div class="h3" id="in-place-import" title="in-place-import">
<h3>How can I do an in-place 'import'
(i.e. add a tree to Subversion such that the original data becomes
a working copy directly)?</h3>
<p>Suppose, for example, that you wanted to put some of /etc under
version control inside your repository:</p>
<pre>
# svn mkdir file:///root/svn-repository/etc \
-m "Make a directory in the repository to correspond to /etc"
# cd /etc
# svn checkout file:///root/svn-repository/etc .
# svn add apache samba alsa X11
# svn commit -m "Initial version of my config files"
</pre>
<p>This takes advantage of a not-immediately-obvious feature of
<tt>svn&nbsp;checkout</tt>: you can check out a directory from the repository
directly into an existing directory. Here, we first make a new empty directory
in the repository, and then check it out into <tt>/etc</tt>, transforming
<tt>/etc</tt> into a working copy. Once that is done, you can use normal
<tt>svn&nbsp;add</tt> commands to select files and subtrees to add to the
repository.</p>
<p>There is an issue filed for enhancing <tt>svn&nbsp;import</tt> to
be able to convert the imported tree to a working copy automatically;
see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1328"
>issue 1328</a>.</p>
</div>
<div class="h3" id="dumpload" title="dumpload">
<h3>What is this "dump/load cycle" people
sometimes talk about when upgrading a Subversion server?</h3>
<p>Subversion's repository database schema has changed occasionally
during development. Old repositories, created with a pre-1.0
development version of Subversion, may require the following operation
when upgrading. If a schema change happens between Subversion
releases X and Y, then repository administrators upgrading to Y must
do the following: </p>
<ol>
<li>Shut down svnserve, Apache, and anything else that might be
accessing the repository.
</li>
<li>
<b>
<tt>svnadmin&nbsp;dump&nbsp;/path/to/repository&nbsp;>&nbsp;dumpfile.txt</tt>
</b>,
using version X of svnadmin.
</li>
<li>
<b>
<tt>mv&nbsp;/path/to/repository&nbsp;/path/to/saved-old-repository</tt>
</b>
</li>
<li>Now upgrade to Subversion Y (i.e., build and install Y, replacing X).
</li>
<li>
<b><tt>svnadmin&nbsp;create&nbsp;/path/to/repository</tt></b>, using version
Y of svnadmin.
</li>
<li>
<b>
<tt>svnadmin&nbsp;load&nbsp;/path/to/repository&nbsp;&lt;&nbsp;dumpfile.txt</tt>
</b>,
again using version Y of svnadmin.
</li>
<li>Copy over hook scripts, etc, from the old repository to the new one.
</li>
<li>Restart svnserve, Apache, etc.
</li>
</ol>
<p> See
<a href="http://svnbook.red-bean.com/html-chunk/ch05s03.html#svn-ch-5-sect-3.4"
>http://svnbook.red-bean.com/html-chunk/ch05s03.html#svn-ch-5-sect-3.4</a>
for more details on dumping and loading.</p>
<p> <b>Note</b>: Most upgrades of Subversion do <i>not</i> involve a
dump and load. When one is required, the release announcement and the
CHANGES file for the new version will carry prominent notices about
it. If you don't see such a notice, then there has been no schema
change, and no dump/load is necessary. </p>
</div>
<div class="h3" id="sspi" title="sspi">
<h3>How do I allow clients to authenticate against a
Windows domain controller using SSPI authentication?</h3>
<p><a href="http://tortoisesvn.tigris.org">TortoiseSVN</a> has an excellent
document that describes setting up a Subversion server on Windows. Go to
<a href="http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup.html#tsvn-serversetup-apache-5"
>http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup.html#tsvn-serversetup-apache-5</a>,
to see the section on SSPI authentication.</p>
<p>An important part of the configuration is the line:</p>
<pre>
SSPIOfferBasic On
</pre>
<p>Without this line, browsers that support SSPI will prompt for the user's
credentials, but clients that do not suppport SSPI such as Subversion
will not prompt. (The current release of Neon - Subversion's HTTP
library - handles only basic authentication.) Because the client never
asks for credentials, any action that requires authentication will fail.
Adding this line tells <tt>mod_auth_sspi</tt> to use basic authentication with
the client, but to use the Windows domain controller to authenticate
the credentials.</p>
</div>
<div class="h3" id="adm-dir" title="adm-dir">
<h3>I don't like the ".svn" directory name, and
prefer "SVN" or something else. How do I change it?</h3>
<p>We recommend that you live with ".svn" if you possibly can.
However, if you are using ASP.NET under Windows, you might need to set
the environment variable SVN_ASP_DOT_NET_HACK, as
described <a href="#vs-asp-net">here</a>.</p>
<p>Or you could use a completely custom name for the administrative
directory. We recommend against this, because your working copy would
probably not work with Subversion clients other than the one you
customized. However, if you absolutely must do this, just change this
line in <tt>subversion/include/svn_wc.h</tt> from</p>
<pre>
#define SVN_WC_ADM_DIR_NAME ".svn"
</pre>
<p>
to (for example)
</p>
<pre>
#define SVN_WC_ADM_DIR_NAME "SVN"
</pre>
<p>
then recompile your client.
</p>
</div>
<div class="h3" id="case-change" title="case-change">
<h3>How do I change the case of a filename?</h3>
<p>This problem comes up in two situations. If you're adding files on
an operating system with a case-insensitive filesystem, such as
Windows, you might find you accidentally add a file with the wrong
case in the filename. Alternatively, you may just decide to change
the case of an existing file in the repository.</p>
<p>If you're working in a case-sensitive file system, this is no
problem at all. Just move the file to the new name, e.g.,</p>
<pre>
svn&nbsp;mv&nbsp;file.java&nbsp;File.java
</pre>
<p>But this won't work in a case-insensitive operating system like
Windows. In Windows you can accomplish this by copying the file
somewhere temporary, deleting the file from Subversion, then adding
the copy with the correct case. Or a better way is to perform a move
operation with Subversion URLs. Using URLs is recommended, because it
will preserve history for the file, and will take effect
immediately.</p>
<p>Both ways will leave Windows working copies with problems, however,
because Windows can still get confused when trying to update the
conflicting filenames. (You'll get a message like <tt>svn: Failed to
add file 'File.java': object of the same name already
exists</tt>). One way of fixing the problem is to delete your working
copy and check out again. If you do not want to do this, you must
perform a two step update.</p>
<p>For each file with the wrong case, the following command will change
the case:</p>
<pre>
svn mv svn://svnserver/path/to/file.java svn://svnserver/path/to/File.java
</pre>
<p>To update the working copy, change to the relevant directory and do:</p>
<pre>
svn update file.java
svn update
</pre>
<p>The first update will remove <tt>file.java</tt> from your working
copy, the second update will add <tt>File.java</tt>, leaving you with
a correct working copy. Or if you had a lot of problematic files, you
can update the working copy this way:</p>
<pre>
svn update *
svn update
</pre>
<p>As you can see, adding a file with the wrong case is tricky to fix on
an operating system that has a case insensitive filesystem. Do try to
get it right when you add the file the first time! To prevent the
problem from occurring in the first place, you can create a pre-commit hook that
calls the file <tt>check-case-insensitive.pl</tt>. That file lives
in the Subversion
source tarball, in the directory <tt>contrib/hook-scripts</tt>.</p>
</div>
<div class="h3" id="merge-using-tags" title="merge-using-tags">
<h3>I can't use tags to merge changes from a
branch into the trunk like I used to with CVS, can I?</h3>
<p>As shown below it is possible to merge from a branch to the trunk
without remembering one revision number. Or vice versa (not shown in the
example).</p>
<p>The example below presumes an existing repository in <tt>/home/repos</tt>
in which you want to start a branch named <tt>bar</tt> containing a file
named <tt>foo</tt> you are going to edit.</p>
<p>For the purpose of tracing branch merges, this repository has set up
<tt>tags/branch_traces/</tt> to keep tags.</p>
<pre># setup branch and tags
$ svn copy file:///home/repos/trunk \
file:///home/repos/branches/bar_branch \
-m "start of bar branch"
$ svn copy file:///home/repos/branches/bar_branch \
file:///home/repos/tags/branch_traces/bar_last_merge \
-m "start"
# checkout branch working copy
$ svn checkout file:///home/repos/branches/bar_branch wc
$ cd wc
# edit foo.txt file and commit
$ echo "some text" &gt;&gt;foo.txt
$ svn commit -m "edited foo"
# switch to trunk and merge changes from branch
$ svn switch file:///home/repos/trunk
$ svn merge file:///home/repos/tags/branch_traces/bar_last_merge \
file:///home/repos/branches/bar_branch
# Now check the file content of 'foo.txt', it should contain the changes.
# commit the merge
$ svn commit -m "Merge change X from bar_branch."
# finally, update the trace branch to reflect the new state of things
$ svn delete -m "Remove old trace branch in preparation for refresh." \
file:///home/repos/tags/branch_traces/bar_last_merge
$ svn copy file:///home/repos/branches/bar_branch \
file:///home/repos/tags/branch_traces/bar_last_merge \
-m "Reflect merge of change X."
</pre>
</div>
<div class="h3" id="version-value-in-source" title="version-value-in-source">
<h3>Why doesn't the $Revision$
keyword do what I want? It expands to the file's last-changed revision,
but I want something that will expand to the file's current revision.</h3>
<p>
Subversion increments the revision number of the repository as a
whole, so it can't expand any keyword to be that number - it would
have to search and possibly modify every file in your working copy on
every update and commit.
</p>
<p>
The information you want (the revision of your working copy) is
available from the command <tt>svnversion</tt>; it gives you
information on the revision level of a working copy given a path (see
<tt>svnversion --help</tt> for details).
</p>
<p>
You can incorporate it into your build or release process to get the
information you need into the source itself. For example, in a build
environment based on <tt>GNU&nbsp;make</tt>, add <a
href="http://subversion.tigris.org/servlets/ReadMsg?list=dev&amp;msgNo=112564"
>something like this</a> to your <tt>Makefile</tt>:
</p>
<pre>
##
## To use this, in yourfile.c do something like this:
## printf("this program was compiled from SVN revision %s\n",SVN_REV);
##
SVNDEF := -D'SVN_REV="$(shell svnversion -n .)"'
CFLAGS := $(SVNDEF) ... continue with your other flags ...
</pre>
<p>
(Note that this will not work on non-GNU versions of <tt>make</tt>.
Don't use it if your build process needs to be portable.)</p>
<p>Or try this recipe:</p>
<pre>
##
## on every build, record the working copy revision string
##
svn_version.c: FORCE
echo -n 'const char* svn_version(void) { const char* SVN_Version = "' \
&gt; svn_version.c
svnversion -n . &gt;&gt; svn_version.c
echo '"; return SVN_Version; }' &gt;&gt; svn_version.c
##
## Then any executable that links in <tt>svn_version.o</tt> will be able
## to call the function <tt>svn_version()</tt> to get a string that
## describes exactly what revision was built.
##
</pre>
<p>
Windows users may want to use <tt>SubWCRev.exe</tt>, available from
the <a
href='http://tortoisesvn.net/downloads'>TortoiseSVN
download page</a>; it replaces all <tt>$WCREV$</tt> tags in a given
file with the current working copy revision.
</p>
</div>
<div class="h3" id="log-in-source" title="log-in-source">
<h3>Does Subversion have a keyword which
behaves like $Log$ in CVS?</h3>
<p>No. There is no equivalent for the $Log$ keyword in CVS. If you
want to retrieve a log for a specific file, you can run
'svn log your-file-name' or 'svn log url-to-your-file'.
From the mailing list some explanations why $Log$ is bad:</p>
<pre>"$Log$ is a total horror the moment you start merging changes
between branches. You're practically guaranteed to get conflicts there,
which -- because of the nature of this keyword -- simply cannot be
resolved automatically."</pre>
<p>And:</p>
<pre>Subversion log messages are mutable, they can be changed by setting
the svn:log revision property. So the expansion of $Log:$ in any
given file could be out of date. Update may well need to retrieve the
appropriate log message for each occurrence of the $Log:$ keyword,
even if the file that contained it was not otherwise updated.</pre>
<p><i>I don't care about that. I want to use it anyway.
Will you implement it?</i></p>
<p>No. There are no plans to implement it ourselves or accept patches
which implement this feature. If you want to distribute your files
with some kind of changelog included, you might be able to work
around this limitation in your build system.</p>
</div>
<div class="h3" id="ignore-commit" title="ignore-commit">
<h3>I have a file in my project that every
developer must change, but I don't want those local mods to ever be
committed. How can I make 'svn commit' ignore the file?</h3>
<p>The answer is: don't put that file under version control. Instead,
put a <em>template</em> of the file under version control, something
like "file.tmpl".</p>
<p>Then, after the initial 'svn checkout', have your users (or your
build system) do a normal OS copy of the template to the proper
filename, and have users customize the copy. The file is unversioned,
so it will never be committed. And if you wish, you can add the file
to its parent directory's svn:ignore property, so it doesn't show up
as '?' in the 'svn status' command.</p>
</div>
<div class="h3" id="ssh-auth-cache" title="ssh-auth-cache">
<h3>When I access a repository using
svn+ssh, my password is not cached in ~/.subversion/auth/. How do
I avoid having to type it so often?</h3>
<p>ssh has its own passphrases and its own authentication-caching
scheme. Its auth caching is external to Subversion, and must be set
up independently of Subversion.</p>
<p>OpenSSH includes <b><tt>ssh-keygen</tt></b> to create the keys,
<b><tt>ssh-agent</tt></b> to cache passphrases, and
<b><tt>ssh-add</tt></b> to add passphrases to the agent's cache. A
popular script to simplify usage of <tt>ssh-agent</tt> is
<b><tt>keychain</tt></b>. On Windows, <b><tt>PuTTY</tt></b> is a
popular alternative ssh client; see <b><tt>PuTTYgen</tt></b> to import
OpenSSH keys and <b><tt>pageant</tt></b> to cache passphrases.</p>
<p>Setting up <tt>ssh-agent</tt> is outside the scope of this
document, but a <a
href="http://www.google.com/search?hl=en&amp;lr=&amp;ie=UTF-8&amp;q=%22ssh-agent%22"
>Google search for "ssh-agent"</a> will quickly get you answers. Or
if you're <i>really</i> impatient, try one of these:</p>
<pre>
<a href="http://mah.everybody.org/docs/ssh"
>http://mah.everybody.org/docs/ssh</a>
<a href="http://kimmo.suominen.com/docs/ssh/"
>http://kimmo.suominen.com/docs/ssh/</a>
</pre>
</div>
<div class="h3" id="ssh-svnserve-location" title="ssh-svnserve-location">
<h3>My
<tt>svnserve</tt> binary is in a directory that isn't on my
users' default <tt>PATH</tt>s, they use svn+ssh, and I can't figure
out how to modify their <tt>PATH</tt> so that they can run <tt>svnserve</tt>.</h3>
<p>Note: this all assumes you're using OpenSSH. There are other
ssh implementations out there, and presumably they will allow
you to do something similar, but we don't yet know the details.</p>
<p>You've tried fiddling with their various login files, like
<tt>.bash_profile</tt>, and nothing works! That's because ssh
ignores those files when the Subversion client invokes it.
But there's no need to modify <tt>PATH</tt>; instead, you can
directly give ssh the full name of the <tt>svnserve</tt> command.
Here's how to do it:</p>
<p>For each user who needs svn+ssh access, generate a new ssh
public-key pair which they will use <em>only</em> for
Subversion&mdash;not for logging in normally. Have them give
the keypair a distinctive name, like
<tt>~/.ssh/id_dsa.subversion</tt>. Add the public part of the
key to their <tt>~/.ssh/authorized_keys</tt> file on the
server machine, after first inserting a bit of magic at the
beginning of the line before the word <tt>ssh-rsa</tt> or
<tt>ssh-dss</tt>, like this:</p>
<table border="1" cellspacing="2" cellpadding="2">
<tr><th>before</th></tr>
<tr><td><tt>ssh-dss&nbsp;AAAAB3Nblahblahblahblah</tt></td></tr>
<tr><th>after</th></tr>
<tr><td><tt>
command="/opt/subversion/bin/svnserve&nbsp;-t"&nbsp;ssh-dss&nbsp;AAAAB3Nblahblahblahblah
</tt></td></tr>
</table>
<p>Obviously, replace <tt>/opt/subversion/bin/svnserve</tt> with
whatever is appropriate for your system. You also might want to
specify the full path to the Subversion repository in the
command (by using the <tt>-r</tt> option), to save your users
some typing.</p>
<p>The <tt>command=</tt> magic causes sshd on the remote machine
to invoke <tt>svnserve</tt>, even if your user tries to run
some other command. See the sshd(8) man page (section
<tt>AUTHORIZED_KEYS FILE FORMAT</tt>) for details.</p>
<p>Now when your users run the Subversion client, make sure they
have an <tt>SVN_SSH</tt> environment variable that "points to"
the private half of their keypair, by doing something like this
(for the Bourne Again shell):</p>
<pre>
SVN_SSH="ssh -i $HOME/.ssh/id_dsa.subversion"
export SVN_SSH
</pre>
<p><a
href="http://svn.collab.net/repos/svn/trunk/notes/ssh-tricks">This
file</a> discusses this topic in more detail.</p>
</div>
<div class="h3" id="ssh-authorized-keys-trick" title="ssh-authorized-keys-trick">
<h3>I want to allow access via svn+ssh://, but am paranoid. I hate the
idea of giving each user a login; I would then have to worry about
what they are, and are not, allowed to access on my machine.</h3>
<p>See the section about hacking
the <tt>~/.ssh/authorized_keys</tt> file in the answer
to <a href="#ssh-svnserve-location">this other question</a>; ignore the stuff
about getting <tt>svnserve</tt> on your PATH.</p>
</div>
<div class="h3" id="auto-props" title="auto-props">
<h3>How can I set certain properties on
everything in the repository? Also, how can I make sure that every
new file coming into the repository has these properties?</h3>
<p>Subversion will not change a file's contents by default; you have
to deliberately set the <tt>svn:eol-style</tt> or
<tt>svn:keywords</tt> property on a file for that to happen. That
makes Subversion a lot safer than CVS's default behavior, but with
that safety comes some inconvenience.</p>
<p>Answering the first question: to set properties on all files
already in the repository, you'll need to do it the hard way. All you
can do is run <tt>svn propset</tt> on every file (in a working copy),
and then <tt>svn commit</tt>. Scripting can probably help you with
this.</p>
<p>But what about future files? Unfortunately, there's no server
mechanism to automatically set properties on files being committed.
This means that all of your users need to remember to set certain
properties whenever they <tt>svn add</tt> a file. Fortunately,
there's a client-side tool to help with this. Read about the <a
href="http://svnbook.red-bean.com/svnbook-1.1/ch07s02.html#svn-ch-7-sect-2.4">
auto-props</a> feature in the book. You need to make sure all your
users configure their clients' auto-props settings appropriately.</p>
<p>You could write a pre-commit hook script to reject any commit which
forgets to add properties to new files (see <a
href="http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl"
>http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl</a>
for example). However, this approach may be overkill. If somebody
forgets to set <tt>svn:eol-style</tt>, for example, it will be noticed
the minute somebody else opens the file on a different OS. Once
noticed, it's easy to fix: just set the property and commit.</p>
<p>Note: many users have asked for a feature whereby the server
automatically "broadcasts" run-time settings to clients, such as
auto-props settings. There's already a feature request filed for this
(<a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=1974">issue
1974</a>), though this feature is still being debated by developers,
and isn't being worked on yet.</p>
</div>
<div class="h3" id="svn-editor" title="auto-props">
<h3>How do I deal with spaces in the editor path?&nbsp; Also, how can
I define command line options for the editor?</h3>
<p>The Subversion command line client will invoke the editor defined
in the environment variable SVN_EDITOR.&nbsp; This environment variable
is passed directly to the operating system along with the name of a
temporary file used to enter/edit the log message.</p>
<p>Due to the fact that the SVN_EDITOR string is passed as-is to the
system's command shell, spaces in the editor name, or in the path name
to the editor, will not work unless the editor name is in quotes.</p>
<p>For example, on Windows if your editor is in
<code>C:\Program&nbsp;Files\Posix&nbsp;Tools\bin\vi</code> you would
want to set the variable as follows:
</p>
<pre>
set SVN_EDITOR="C:\Program Files\Posix Tools\bin\vi"
</pre>
<p>Note that there is no need to escape the quotes in the Windows
shell as they are not part of the syntax for the <code>set</code>
command.
</p>
<p>On UNIX systems you would need to follow your shell's specific
methods for setting the variable.&nbsp; For example, in a bash shell,
the following should work:
</p>
<pre>
SVN_EDITOR='"/usr/local/more editors/bin/xemacs"'
export SVN_EDITOR
</pre>
<p>In case a command line option would be needed for the invocation
of the editor, just add that after the editor name in the SVN_EDITOR
environment variable just like you would us on the command line.&nbsp;
For example, if the options <code>-nx -r</code> would be wanted for
the above editors, the following will provide those options:
</p>
<p>For Windows:</p>
<pre>
set SVN_EDITOR="C:\Program Files\Posix Tools\bin\vi" -nx -r
</pre>
<p>For UNIX/bash:</p>
<pre>
SVN_EDITOR='"/usr/local/more editors/bin/xemacs" -nx -r'
export SVN_EDITOR
</pre>
<p>Note that SVN_EDITOR is the Subversion specific environment variable
setting for the editor selection.&nbsp; Subversion also supports
using the more generic EDITOR variable but if you need special behaviors
with Subversion it is best to use the SVN_EDITOR variable.
</p>
</div>
<div class="h3" id="divining-bdb-version" title="divining-bdb-version">
<h3>How do I determine which version of
Berkeley DB a repository is using?</h3>
<p>If it's a live repository, then the easy answer is "Whatever
version of Berkeley DB you have installed". If, however, it is a
repository from a backup, or some unknown source, and you have no idea
which version of Berkeley DB it was made with, here's how you find
out:</p>
<p>Run some command to view the two 4-byte integers at offsets 12 and
16 (decimal) in the highest-numbered db/log.* file in the repository.
Here is an example using GNU od: "<tt>od -j12 -N8 -tx4
log.<i>&lt;number&gt;</i></tt>". Here is an example using Mac OS X
hexdump: "<tt>hexdump -s12 -n8 -x log.<i>&lt;number&gt;</i></tt>".
The first integer should be the magic number 0x00040988, which
identifies the file as a Berkeley DB logfile. The second number is
the log format version
- match it to a Berkeley DB version using the table below:</p>
<table border="1" cellspacing="2" cellpadding="2">
<tr><th>Log format version</th><th>Berkeley DB version</th></tr>
<tr><td>5 (0x00000005)</td><td>4.0</td></tr>
<tr><td>7 (0x00000007)</td><td>4.1</td></tr>
<tr><td>8 (0x00000008)</td><td>4.2</td></tr>
<tr><td>10 (0x0000000a)</td><td>4.3</td></tr>
<tr><td>11 (0x0000000b)</td><td>4.4</td></tr>
</table>
</div>
<div class="h3" id="website-auto-update" title="website-auto-update">
<h3>I'm managing a website in my
repository. How can I make the live site automatically update after
every commit?</h3>
<p>This is done all the time, and is easily accomplished by adding a
post-commit hook script to your repository. Read about hook scripts
in <a
href="http://svnbook.red-bean.com/en/1.1/ch05s02.html#svn-ch-5-sect-2.1">Chapter
5</a> of the book. The basic idea is to make the "live site" just an
ordinary working copy, and then have your post-commit hook script run
'svn update' on it.</p>
<p>In practice, there are a couple of things to watch out for. The
server program performing the commit (svnserve or apache) is the same
program that will be running the post-commit hook script. That means
that this program must have proper permissions to update the working
copy. In other words, the working copy must be owned by the same user
that svnserve or apache runs as -- or at least the working copy must
have appropriate permissions set.</p>
<p>If the server needs to update a working copy that it doesn't own
(for example, user joe's ~/public_html/ area), one technique is create
a +s binary program to run the update, since Unix won't allow scripts
to run +s. Compile a tiny C program:</p>
<pre>
#include &lt;stddef.h&gt;
#include &lt;stdlib.h&gt;
#include &lt;unistd.h&gt;
int main(void)
{
execl("/usr/local/bin/svn", "svn", "update", "/home/joe/public_html/",
(const char *) NULL);
return(EXIT_FAILURE);
}
</pre>
<p>... and then <tt>chmod +s</tt> the binary, and make sure it's owned
by user 'joe'. Then in the post-commit hook, add a line to run the
binary.</p>
<p>If you have problems getting the hook to work, see <a
href="#hook-debugging">"Why aren't my repository hooks
working?"</a>.</p>
<p>Also, you'll probably want to prevent apache from exporting the
.svn/ directories in the live working copy. Add this to your
<tt>httpd.conf</tt>:</p>
<pre>
# Disallow browsing of Subversion working copy administrative dirs.
&lt;DirectoryMatch "^/.*/\.svn/"&gt;
Order deny,allow
Deny from all
&lt;/DirectoryMatch&gt;
</pre>
</div>
<div class="h3" id="single-file-checkout" title="single-file-checkout">
<h3>How do I check out a single file?</h3>
<p>Subversion does not support checkout of a single file, it only
supports checkout of directory structures.</p>
<p>However, you can use 'svn export' to export a single file. This will
retrieve the file's contents, it just won't create a versioned working
copy.</p>
</div>
<div class="h3" id="wc-change-detection" title="wc-change-detection">
<h3>How do I detect adds, deletes,
copies and renames in a working copy after they've already
happened?</h3>
<p>You don't. It's a bad idea to try.</p>
<p>The basic design of the working copy has two rules: (1) edit files
as you please, and (2) use a Subversion client to make any
tree-changes (add, delete, move, copy). If these rules are followed,
the client can sucessfully manage the working copy. If renames or
other rearrangements happen outside of Subversion, then the UI has
been violated and the working copy might be broken. The client cannot
guess what happened.</p>
<p>People sometimes run into this problem because they want to make
version control "transparent". They trick users into using a working
copy, then have a script run later that tries to guess what happened
and run appropriate client commands. Unfortunately, this technique
only goes a short distance. 'svn status' will show missing items and
unversioned items, which the script can then automatically 'svn rm' or
'svn add'. But if a move or copy has happened, you're out of luck.
Even if the script has a foolproof way of detecting these things, 'svn
mv' and 'svn cp' can't operate after the action has already
occurred.</p>
<p>In summary: a working copy is wholly under Subversion's control,
and Subversion wasn't designed to be transparent. If you're looking
for transparency, try setting up an apache server and using the
"SVNAutoversioning" feature described in appendix C of the book. This
will allow users to mount the repository as a network disk, and any
changes made to the volume cause automatic commits on the server.</p>
</div>
<div class="h3" id="svnserve-win-service" title="svnserve-win-service">
<h3>How do I run svnserve as a service
on Windows?</h3>
<p>For versions 1.4.0 and later, you can find
instructions <a
href="http://svn.collab.net/repos/svn/trunk/notes/windows-service.txt">here</a>.</p>
<p>In versions before 1.4.0, the <tt>svnserve</tt> binary itself could
not be installed as a Windows service, but there are a number of
&ldquo;service wrappers&rdquo; that can do the job; for example:</p>
<ul>
<li><a href="http://www.clanlib.org/~mbn/svnservice/">SVNService</a>
is a free tool written by Magnus Norddahl</li>
<li><a href="http://support.microsoft.com/kb/q137890/">SrvAny</a>
is avaliable free of charge from Microsoft</li>
</ul>
<p>There is a bit more about running <tt>svnserve</tt> as a service in
<a
href="http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-svnserve.html">the
TortoiseSVN manual</a>.</p>
</div>
<div class="h3" id="bdb-fsfs-convert" title="bdb-fsfs-convert">
<h3>How do I convert my repository from using BDB
to FSFS or from FSFS to BDB?</h3>
<p>There are three steps:</p>
<ol>
<li>A <a href="#dumpload">dump/load</a> from the old format to the new
one.</li>
<li>Copy the hook scripts.</li>
<li>Copy the configuration files.</li>
</ol>
<p>Say you have a repository <tt>/svn/myrepos</tt> which is using the BDB
backend and you would like to switch to using the FSFS backend:</p>
<ol>
<li>Close down your server so that the data cannot change during this
procedure.</li>
<li>Make a new repository specifying the fsfs backend (it is the default
from 1.2 onwards), e.g., <tt>svnadmin create /svn/myreposfsfs --fs-type
fsfs</tt>.</li>
<li>Pipe the output of a dump from <tt>/svn/myrepos</tt> to the input of a
load into <tt>/svn/myreposfsfs</tt>, e.g., <tt>svnadmin dump /svn/myrepos
-q | svnadmin load /svn/myreposfsfs</tt>. Windows users should dump
to a file and load from that file in two separate steps.</li>
<li>Copy any hook scripts which are active in <tt>/svn/myrepos/hooks</tt>
into <tt>/svn/myreposfsfs/hooks</tt>. Don't mindlessly copy everything, the
templates generated by Subversion may have changed.</li>
<li>Compare the template scripts which the <tt>svnadmin create</tt> command
put in <tt>/svn/myreposfsfs/hooks</tt> with those in
<tt>/svn/myrepos/hooks</tt> and incorporate any changes which you would like
into your active hook scripts.</li>
<li>Copy configuration files from <tt>/svn/myrepos/conf</tt>
into <tt>/svn/myreposfsfs/conf</tt> (and don't forget a password
file, if you use one). Or you might instead want to merge
the <em>changes</em> that you made to your configuration files into
the new default ones.</li>
<li>Rename <tt>/svn/myrepos</tt> to <tt>/svn/myreposbdb</tt> and then
<tt>/svn/myreposfsfs</tt> to <tt>/svn/myrepos</tt> ensuring that the
file permissions are the same as those that the BDB version had.</li>
<li>Restart the server.</li>
</ol>
<p>Once you are happy that all is well with your new repository delete the old
one.</p>
<p>To do the reverse and migrate from FSFS to BDB change the <tt>svnadmin
create</tt> command to specify BDB.</p>
</div>
<div class="h3" id="binary-files" title="binary-files">
<h3>How does Subversion handle binary files?</h3>
<p>When you first add or import a file into Subversion, the file is
examined to determine if it is a binary file. Currently, Subversion
just looks at the first 1024 bytes of the file; if any of the bytes
are zero, or if more than 15% are not ASCII printing characters, then
Subversion calls the file binary. This heuristic might be improved in
the future, however.</p>
<p>If Subversion determines that the file is binary, the file receives
an svn:mime-type property set to "application/octet-stream". (You can
always override this by using the <a
href="http://svnbook.red-bean.com/svnbook-1.1/ch07s02.html#svn-ch-7-sect-2.4"
>auto-props feature</a> or by setting the property manually with
<tt>svn propset</tt>.)</p>
<p>Subversion treats the following files as text:</p>
<ul>
<li>Files with no svn:mime-type</li>
<li>Files with a svn:mime-type starting "text/"</li>
<li>Files with a svn:mime-type equal to "image/x-xbitmap"</li>
<li>Files with a svn:mime-type equal to "image/x-xpixmap"</li>
</ul>
<p>All other files are treated as binary, meaning that Subversion will:</p>
<ul>
<li>Not attempt to automatically merge received changes with local
changes during <tt>svn update</tt> or <tt>svn merge</tt></li>
<li>Not show the differences as part of <tt>svn diff</tt></li>
<li>Not show line-by-line attribution for <tt>svn blame</tt></li>
</ul>
<p>In all other respects, Subversion treats binary files the same as
text files, e.g. if you set the svn:keywords or svn:eol-style
properties, Subversion will perform keyword substitution or newline
conversion on binary files.</p>
<p>Note that whether or not a file is binary does not affect the
amount of repository space used to store changes to that file, nor
does it affect the amount of traffic between client and server. For
storage and transmission purposes, Subversion uses a diffing method
that works equally well on binary and text files; this is completely
unrelated to the diffing method used by the 'svn&nbsp;diff'
command.</p>
</div>
<div class="h3" id="terse-diff" title="terse-diff">
<h3>How can I make <tt>svn diff</tt> show me just the names of the
changed files, not their contents?</h3>
<p>
<tt>svn diff</tt> doesn't have an option to do this, but
</p>
<ul>
<li>
If you only are interested in the diffs between, say, revision 10
and the revision just before it, <pre>svn log -vq -r10</pre> does
exactly what you want;
</li>
<li>
otherwise, if you're using Unix, this works for any range of revisions:
<pre>
svn log -vq -r123:456 | egrep '^ {3}[ADMR] ' | cut -c6- | sort | uniq </pre> </li>
</ul>
Version 1.4 of the <tt>svn diff</tt> command will have a "--summarize"
option.
</div>
<div class="h3" id="sorry-no-globbing" title="sorry-no-globbing">
<h3>How can I use wildcards or globbing to move many files at once?</h3>
<p>
You want to do something like
</p>
<pre>
svn mv svn://server/trunk/stuff/* svn://server/trunk/some-other-dir
</pre>
<p>
but it fails with
</p>
<pre>
svn: Path 'svn://server/trunk/stuff/*' does not exist in revision 123
</pre>
<p>
... or some other inscrutable error message.
</p>
<p>
The short, unhappy answer is: there's no built-in way to do this; many
commands, like <tt>mv</tt>, refuse to take an arbitrary number of
arguments ... and in any case, Subversion doesn't expand wildcards like
"*" the way the shell does.
</p>
<p>
If you happen to have a working copy that contains all the source
files as well as the destination directory, then you can exploit your
shell's wildcard feature to do the move, like this (for Bash):
</p>
<pre>
for i in stuff/*; do svn mv $i some-other-dir; done
svn ci -m "moved all the stuff into some other dir"
</pre>
<p>
In any case, you can always accumulate a list of the names of the
source files, and then run "svn mv" on each item in that list, like
this:
</p>
<pre>
s=svn://server/trunk/stuff/
svn ls "$s" | \
while read f
do svn mv "$s/$f" svn://server/trunk/some-other-dir -m "Moved just one file"
done
</pre>
<p>
Note, however, that this will generate one commit per source file;
that's in contrast to the above method (using a working copy) which
generates just one commit total.
</p>
<p>
There is a program called "svnmucc" or "mucc" depending upon which
version of Subversion you have, whose source is distributed with
Subversion (in ...<tt>/contrib/client-side/mucc/mucc.c</tt> for
Subversion 1.4 or earlier, in
...<tt>/contrib/client-side/svnmucc/svnmucc.c</tt> for Subversion 1.5
or later), that appears to solve this problem for you.
</p>
<p>
Rumor has it that with release 1.5, Subversion will in fact allow you
to "cp" and "mv" multiple files at once.
</p>
</div>
<div class="h3" id="vendor-branch" title="vendor-branch">
<h3>How can I maintain a modified version (a "vendor branch") of
third-party software using Subversion?</h3>
<p>People frequently want to use Subversion to track their local
changes to third-party code, even across upgrades from the
third-party&nbsp;&mdash;&nbsp;that is, they want to maintain their own
divergent branch, while still incorporating new releases from the
upstream source. This is commonly called a <em>vendor branch</em>
(the term long predates Subversion), and the techniques for
maintaining one in Subversion are <a
href="http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.vendorbr"
>described here</a>.</p>
<p>If the vendor code is hosted in a remote Subversion repository,
then you can use <a href="http://piston.rubyforge.org/">Piston</a> to
manage your copy of the vendor's code.</p>
<p>As a last resort, if using <tt>svn_load_dirs.pl</tt> is taking too
much time or you're looking for the lazy solution, see also Jon
Stevens' step-by-step explanation at <a
href="http://lookfirst.com/2007/11/subversion-vendor-branches-howto.html"
>Subversion Vendor Branches Howto</a>. This solution does not make
use of the space saving features in the Subversion backend when you
copy new code over old code; in this solution, each import of a vendor
code gets an entire new copy and there is no space savings for
identical files.</p>
</div>
</div>
<div class="h2" id="troubleshooting" title="troubleshooting">
<h2>Troubleshooting:</h2>
<p/>
<div id="permissions"></div>
<div class="h3" id="stuck-bdb-repos" title="stuck-bdb-repos">
<h3>My repository seems to get stuck all the
time, giving me errors about needing recovery (DB_RUNRECOVERY). What
could be the cause?</h3>
<p>The Berkeley DB database in your repository is sensitive to
interruptions. If a process accessing the database exits without
"cleanly" closing the environment, then the database is left in an
inconsistent state. Common causes of this include:</p>
<ul>
<li>the process exiting when it hits a permission problem</li>
<li>the process crashing/segfaulting</li>
<li>the process being forcibly killed</li>
<li>running out of disk space</li>
</ul>
<p>For most of these cases, you should run "svnadmin recover", which
rewinds the repository back to a consistent state; see <a
href="#bdb-recovery">this question</a> for details. Note that running
out of disk space, combined with frequent checkouts or updates, can
cause the repository to crash in a way where recovery is not possible
(so keep backups).</p>
<p>Segfaults, forced killings, and running out of disk space are
pretty rare. Permission problems are far more common: one process
accesses the repository and accidentally changes ownership or
permissions, then another process tries to access and chokes on the
permissions.</p>
<p>The best way to prevent this is to get your repository permissions
and ownership set up correctly. See <a href="#reposperms">here</a>
for our recommendations.</p>
</div>
<div id="wedged-repos"></div>
<div class="h3" id="bdb-recovery" title="bdb-recovery">
<h3>Every time I try to access my repository, the
process just hangs. Is my repository corrupt?</h3>
<p>
Your repository is not corrupt, nor is your data lost. If your process
accesses the repository directly (mod_dav_svn, svnlook, svnadmin, or
if you access a `file://' URL), then it's using Berkeley DB to access
your data. Berkeley DB is a journaling system, meaning that it logs
everything it is about to do before it does so. If your process is
interrupted (Control-C, or segfault), then a lockfile is left behind,
along with a logfile describing unfinished business. Any other
process that attempts to access the database will just hang, waiting
for the lockfile to disappear. To awaken your repository, you need to
ask Berkeley DB to either finish the work, or rewind the database to a
previous state that is known to be consistent.</p>
<p><b><span style="color: red">WARNING:</span> you can seriously corrupt
your repository if you run recover and another process accesses the
repository.</b></p>
<p>Make absolutely sure you disable all access to the repository before
doing this (by shutting down Apache, removing executable permissions from
'svn'). Make sure you run this command as the user that owns and manages
the database, and not as root, else it will leave root-owned files in the
db directory which cannot be opened by the non-root user that manages the
database, which is typically either you or your Apache process. Also be
sure to have the correct umask set when you run recover, since failing to
do so will lock out users that are in the group allowed to access the
repository.</p>
<p>
Simply run:</p>
<pre>
svnadmin recover /path/to/repos
</pre>
<p>Once the command has completed, check the permissions in the
<code>db</code> directory of the repository.</p>
<p>Sometimes "svnadmin&nbsp;recover" doesn't work. You may see it
give errors like this:</p>
<pre>
Repository lock acquired.
Please wait; recovering the repository may take some time...
svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery
svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass
svnadmin: bdb: PANIC: No such file or directory
svnadmin: bdb: PANIC: fatal region error detected; run recovery
</pre>
<p>or like this:</p>
<pre>
Repository lock acquired.
Please wait; recovering the repository may take some time...
svn: DB_RUNRECOVERY: Fatal error, run database recovery
svn: bdb: DB_ENV-&gt;log_flush: LSN of 115/802071 past current end-of-log
of 115/731460
svn: bdb: Database environment corrupt; the wrong log files may have
been removed or incompatible database files imported from another
environment
[...]
svn: bdb: changes: unable to flush page: 0
svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument
svn: bdb: PANIC: Invalid argument
svn: bdb: PANIC: fatal region error detected; run recovery
svn: bdb: PANIC: fatal region error detected; run recovery
[...]
</pre>
<p>In that case, try Berkeley DB's native <b>db_recover</b> utility
(see <a href="http://www.oracle.com/technology/documentation/berkeley-db/db/utility/db_recover.html"
>db_recover documentation</a>). It
usually lives in a "bin/" subdirectory of the Berkeley DB installation,
for example if you installed Berkeley DB from source, it might be
<tt>/usr/local/BerkeleyDB.4.2/bin/db_recover</tt>; or on systems where
Berkeley DB comes prepackaged it might just be
<tt>/usr/bin/db_recover</tt>. If you have multiple versions of
Berkeley DB installed, make sure that the version of db_recover you
use matches the version of Berkeley DB with which your repository was
created.</p>
<p>Run db_recover with the "-c" ("catastrophic recovery") flag. You
can also add "-v" for verbosity, and "-h" with an argument telling it
what db environment to recover (so you don't have to cd into that
directory). Thus:</p>
<pre>
db_recover -c -v -h /path/to/repos/db
</pre>
<p>Run this command as the same user that owns the repository, and
again, make absolutely sure that no other processes are accessing the
repository while you do this (e.g., shut down svnserve or Apache).</p>
</div>
<div class="h3" id="bdb-cannot-allocate-memory" title="bdb-cannot-allocate-memory">
<h3>My repository keeps giving errors saying "Cannot allocate memory".
What should I do?</h3>
<p>If you're using http:// access, "<b>Cannot allocate memory</b>"
errors show up in the httpd error log and look something like
this:</p>
<blockquote>
<pre>
[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (20014)
Error string not specified yet: Berkeley DB error while opening
'strings' table for filesystem /usr/local/svn/repositories/svn/db:
Cannot allocate memory
[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]
Could not fetch resource information. [500, #0]
[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]
Could not open the requested SVN filesystem [500, #160029]
[Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (17)
File exists: Could not open the requested SVN filesystem [500, #160029]
</pre>
</blockquote>
<p>It usually means that a Berkeley DB repository has run out of
database locks (this does not happen with FSFS repositories). It
shouldn't happen in the course of normal operations, but if it does,
the solution is to run database recovery as described <a
href="#bdb-recovery">here</a>. If it happens often, you probably need
to raise the default lock parameters (<tt>set_lk_max_locks</tt>,
<tt>set_lk_max_lockers</tt>, and <tt>set_lk_max_objects</tt>) in the
db/DB_CONFIG file. When changing DB_CONFIG in an existing repository,
remember to run recovery afterwards.</p>
</div>
<div class="h3" id="wedged-wc" title="wedged-wc">
<h3>Every time I try to run a svn command, it says my
working copy is locked. Is my working copy corrupt?</h3>
<p>
Your working copy is not corrupt, nor is your data lost. Subversion's
working copy is a journaling system, meaning that it logs everything it
is about to do before it does so. If the svn client program is
interrupted violently (segfault or killed, not with Control-C), then
one or more lockfiles are left behind, along with logfiles describing
unfinished business. (The `svn status' command will show an 'L' next
to locked directories.) Any other process that attempts to access the
working copy will fail when it sees the locks. To awaken your working
copy, you need to tell the svn client to finish the work. Simply
run:</p>
<pre>
svn cleanup working-copy
</pre>
</div>
<div class="h3" id="wc-out-of-date" title="wc-out-of-date">
<h3>I'm trying to commit, but Subversion says my
working copy is out of date?</h3>
<p>Three kinds of situation that can cause this:</p>
<ol>
<li><p>Debris from a failed commit is littering your working copy.</p>
<p>You may have had a commit that went sour between the time the
new revision was added in the server and the time your client
performed its post-commit admin tasks (including refreshing your
local text-base copy). This might happen for various reasons
including (rarely) problems in the database back end or (more
commonly) network dropouts at exactly the wrong time.</p>
<p>If this happens, it's possible that you have already committed
the very changes you are trying now to commit. You can use 'svn
log -rHEAD' to see if your supposed-failed commit actually
succeeded. If it did, run 'svn revert' to revert your local
changes, then run 'svn update' to get your own changes back from the
server. (Note that only 'svn update' brings your local copies
up-to-date; revert doesn't do that.)</p>
</li>
<li><p>Mixed revisions.</p>
<p>When Subversion commits, the client only bumps the revision
numbers of the nodes the commit touches, not all nodes in the
working copy. This means that in a single working copy, the
files and subdirectories might be at different revisions,
depending on when you last committed them. In certain operations
(for example, directory property modifications), if the
repository has a more recent version of the node, the commit will
be rejected, to prevent data loss. See <a
href="http://svnbook.red-bean.com/svnbook/ch02s03.html#svn-ch-2-sect-3.4">
The Limitations of Mixed Revisions</a> in the <a
href="http://svnbook.red-bean.com/">Version Control with
Subversion</a> for details.</p>
<p>You can fix the problem by running 'svn update' in the working
copy.</p>
</li>
<li><p>You might be genuinely out of date&nbsp;&mdash;&nbsp;that is,
you're trying to commit a change to a file that has been changed
by someone else since you last updated your copy of that file.
Again, 'svn update' is the way to fix this.</p>
</li>
</ol>
</div>
<div class="h3" id="obstructed-add" title="obstructed-add">
<h3>I've contributed a patch to a project and the patch added a new file.
Now <tt>svn update</tt> does not work.</h3>
<p>In order to include your new file in the patch you likely ran the <tt>svn add</tt>
command so that the <tt>svn diff</tt> command would include the new file in the patch.
If your patch is committed to the code base and you run an <tt>svn update</tt>, then
you might receive an error message of: "svn: Failed to add file 'my.new.file':
object of the same name already exists".</p>
<p>The reason that you recieved this error is that you still have your local copy of
the file in your working copy. The steps to correct this problem are:</p>
<ol>
<li>Run the <tt>svn revert</tt> command to remove the scheduled add within
Subversion.</li>
<li>Delete the file or move it to a location outside your working copy.</li>
<li>Now you should be able to run the <tt>svn update</tt> command.</li>
</ol>
<p>You might want to compare the new file from the repository with your original file.</p>
</div>
<div class="h3" id="unrecognized-url-error" title="unrecognized-url-error">
<h3>I just built the distribution binary,
and when I try to check out Subversion, I get an error about an
"Unrecognized URL scheme." What's up with that?</h3>
<p>Subversion uses a plugin system to allow access to repositories.
Currently there are three of these plugins: ra_local allows access to
a local repository, ra_dav which allows access to a repository via
WebDAV, and ra_svn allows local or remote access via the svnserve
server. When you attempt to perform an operation in Subversion, the
program tries to dynamically load a plugin based on the URL scheme. A
`file://' URL will try to load ra_local, and an `http://' URL will try
to load ra_dav.</p>
<p>The error you are seeing means that the dynamic linker/loader can't find
the plugins to load. This normally happens when you build Subversion with
shared libraries, then attempt to run it without first running 'make
install'. Another possible cause is that you ran make install, but the
libraries were installed in a location that the dynamic linker/loader
doesn't recognize. Under Linux, you can allow the linker/loader to find the
libraries by adding the library directory to /etc/ld.so.conf and running
ldconfig. If you don't wish to do this, or you don't have root access, you
can also specify the library directory in the LD_LIBRARY_PATH environment
variable.</p>
</div>
<div class="h3" id="db-recover" title="db-recover">
<h3>I'm getting errors finding or opening a repository,
but I know my repository URL is correct. What's wrong?</h3>
<p>See <a href="#bdb-recovery">this faq.</a></p>
</div>
<div class="h3" id="configure-sed-error" title="configure-sed-error">
<h3>When I run `<tt>configure</tt>', I get errors about
<tt>subs-1.sed&nbsp;line&nbsp;38:&nbsp;Unterminated&nbsp;`s'&nbsp;command</tt>.
What's wrong?</h3>
<p>
You probably have old copies of
<tt>/usr/local/bin/apr-config</tt> and
<tt>/usr/local/bin/apu-config</tt> on your system. Remove them, make
sure the <tt>apr/</tt> and <tt>apr-util/</tt> that you're
building with are completely up-to-date, and try again.
</p>
</div>
<div class="h3" id="windows-msvc-build" title="windows-msvc-build">
<h3>I'm having trouble building Subversion
under Windows with MSVC++ 6.0. What should I do?</h3>
<p>
Probably you just need to get the latest platform SDK. The one that
ships with VC++ 6.0 is not recent enough.
</p>
</div>
<div class="h3" id="windows-drive-letter" title="windows-drive-letter">
<h3>How can I specify a Windows drive letter in
a <tt>file:</tt> URL?</h3>
<p>Like this:</p>
<pre>
svn import file:///d:/some/path/to/repos/on/d/drive
</pre>
<p>See <a
href="http://svnbook.red-bean.com/html-chunk/ch02s03.html#svn-ch-2-sidebar-1">
Repository URLs</a> in the Subversion Book for more details.</p>
</div>
<div class="h3" id="vs-asp-net" title="vs-asp-net">
<h3>VS.NET/ASP.NET seems to have a problem with
the ".svn" directory name. What should I do?</h3>
<p>VS.Net has a subsystem called ASP.Net, which uses WebDAV to do
remote publishing through IIS. This subsystem rejects any pathname
that starts with ".". This causes a problem when you try to remotely
publish a Subversion working copy, because of the ".svn"
subdirectories. The error message says something like "unable to
read project information".</p>
<p>To work around this, set the environment variable
SVN_ASP_DOT_NET_HACK to any value&nbsp;&mdash;&nbsp;this will tell
Windows clients to use "_svn" as a directory name in your working
copy. See <a
href="http://subversion.tigris.org/svn_1.3_releasenotes.html#_svn-hack"
>the relevant section of the Subversion 1.3 release notes</a> for more
details, and see <a href="#adm-dir">this question</a> for other ways to
customize the administrative directory name.</p>
</div>
<div class="h3" id="write-over-dav" title="write-over-dav">
<h3>I'm having trouble doing write
operations to a Subversion repository over a network.</h3>
<p>For example, one user reported that imports worked fine over local
access:</p>
<pre>
$ mkdir test
$ touch test/testfile
$ svn import test file:///var/svn/test -m "Initial import"
Adding test/testfile
Transmitting file data .
Committed revision 1.
</pre>
But not from a remote host:
<pre>
$ svn import http://svn.sabi.net/test testfile -m "import"
nicholas's password: xxxxxxx
svn_error: #21110 : &lt;Activity not found&gt;
The specified activity does not exist.
</pre>
<p> We've seen this when the REPOS/dav/ directory is not writable by
the httpd process. Check the permissions to ensure Apache can write
to the <tt>dav/</tt> directory (and to <tt>db/</tt>, of course). </p>
</div>
<div class="h3" id="windows-xp-server" title="windows-xp-server">
<h3>Under Windows XP, the Subversion server
sometimes seems to send out corrupted data. Can this really
be happening?</h3>
<p>You need to install Window XP Service Pack 1. You can get all
sorts of information about that Service Pack here:</p>
<ul><li>
<a href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949"
>http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949</a>
</li></ul>
</div>
<a name="ethereal"></a> <!-- for compatibility with old question -->
<div class="h3" id="net-trace" title="net-trace">
<h3>What is the best method of doing a network
trace of the conversation between a Subversion client and
server?</h3>
<p>Use <a href="http://www.wireshark.org/">Wireshark</a> (formerly
known as "Ethereal") to eavesdrop on the conversation.</p>
<p>First, make sure that between captures within the same wireshark
session, you hit <em>Clear</em>, otherwise filters from one capture
(say, an HTTP capture) might interfere with others (say, an ra_svn
capture). </p>
<p>Assuming you're cleared, then:</p>
<ol>
<li><p>Pull down the <i>Capture</i> menu, and choose
<i>Capture&nbsp;Filters</i>.</p></li>
<li><p>If debugging the http:// (WebDAV) protocol, then in the window
that pops up, choose "<code>HTTP&nbsp;TCP&nbsp;port&nbsp;(80)</code>"
(which should result in the filter string
"<code><i>tcp&nbsp;port&nbsp;http</i></code>").</p>
<p>If debugging the svn:// (ra_svn) protocol, then choose <i>New</i>,
give the new filter a name (say, "ra_svn"), and type
"<code>tcp&nbsp;port&nbsp;3690</code>" into the filter string box.</p>
<p>When done, click OK.</p></li>
<li><p>Again go to the <i>Capture</i> menu, this time choose
<i>Interfaces</i>, and click <i>Options</i> next to the
appropriate interface (probably you want interface "lo", for
"loopback", assuming the server will run on the same machine as
the client).</p></li>
<li><p>Turn off promiscuous mode by unchecking the appropriate
checkbox.</p></li>
<li><p>Click the <i>Start</i> button in the lower right to start the
capture.</p></li>
<li><p>Run your Subversion client.</p></li>
<li><p>Click the Stop icon (a red X over an ethernet interface card) when
the operation is finished (or <i>Capture-&gt;Stop</i> should
work). Now you have a capture. It looks like a huge list of
lines.</p></li>
<li><p>Click on the <i>Protocol</i> column to sort.</p></li>
<li><p>Then, click on the first relevant line to select it; usually this
is just the first line.</p></li>
<li><p>Right click, and choose <i>Follow TCP Stream</i>. You'll be
presented with the request/response pairs of the Subversion
client's HTTP conversion.</p></li>
</ol>
<p>The above instructions are specific to the graphical version of
Wireshark (version 0.99.6), and don't apply to the command-line
version known as "tshark" (which corresponds to "tethereal", from back
when Wireshark was called Ethereal).</p>
<p>Alternatively, you may set the <tt>neon-debug-mask</tt> parameter in your
<tt>servers</tt> configuration file to cause neon's debugging output
to appear when you run the <tt>svn</tt> client. The numeric value of
<tt>neon-debug-mask</tt> is a combination of the <tt>NE_DBG_...</tt> values
in the header file <tt>ne_utils.h</tt>. For current versions of neon, setting
<tt>neon-debug-mask</tt> to 130 (i.e. <tt>NE_DBG_HTTP+NE_DBG_HTTPBODY)</tt>
will cause the HTTP data to be shown.</p>
<p>You may well want to disable compression when doing a network
trace&mdash;see the <tt>http-compression</tt> parameter in the <tt>servers</tt>
configuration file.</p>
</div>
<div class="h3" id="revert" title="revert">
<h3>Why does the <tt>svn revert</tt> require an
explicit target? Why is it not recursive by default? These
behaviors differ from almost all the other subcommands.</h3>
<p>The short answer: it's for your own good.</p>
<p>Subversion places a very high priority on protecting your data, and
not just your versioned data. Modifications that you make to
already-versioned files, and new files scheduled for addition to the
version control system, must be treated with care.</p>
<p>Making the <tt>svn revert</tt> command require an explicit
target&mdash;even if that target is just '.'&mdash;is one way of
accomplishing that. This requirement (as well as requiring you to
supply the <tt>--recursive (-R)</tt> flag if you want that behavior)
is intended to make you really think about what you're doing, because
once your files are reverted, your local modifications are gone
forever.</p>
</div>
<div class="h3" id="db3db4" title="db3db4">
<h3>When I start Apache, mod_dav_svn complains about
a "bad database version", that it found db-3.X, rather than
db-4.X.</h3>
<p>Your apr-util linked against DB-3, and svn linked against DB-4.
Unfortunately, the DB symbols aren't different. When mod_dav_svn is
loaded into Apache's process-space, it ends up resolving the
symbol names against apr-util's DB-3 library.</p>
<p>The solution is to make sure apr-util compiles against DB-4. You
can do this by passing specific switches to either apr-util's or
apache's configure: "--with-dbm=db4 --with-berkeley-db=/the/db/prefix".</p>
</div>
<div class="h3" id="redhat-db" title="redhat-db">
<h3>I'm getting "Function not implemented" errors on Red Hat
9, and nothing works. How do I fix this?</h3>
<p>This is not really a problem with Subversion, but it often affects
Subversion users.</p>
<p>Red Hat 9 and Fedora ship with a Berkeley DB library that relies on
the kernel support for NPTL (the Native Posix Threads Library).</p>
<p>The kernels that Red Hat provides have this support built in, but if you
compile your own kernel, then you may well not have the NPTL support. If that
is the case, then you will see errors like this:</p>
<blockquote><pre>
svn: Berkeley DB error
svn: Berkeley DB error while creating environment for filesystem tester/db:
Function not implemented
</pre></blockquote>
<p>This can be fixed in one of several ways:</p>
<ul>
<li>Rebuild Berkeley DB for the kernel you're using.</li>
<li>Use a Red Hat 9 kernel.</li>
<li>Apply the NPTL patches to the kernel you're using.</li>
<li>Use a recent (2.5.x) kernel with the NPTL support included.</li>
<li>Check if environment variable <code>LD_ASSUME_KERNEL</code> is set
to <code>2.2.5</code>, and if so, unset it before starting
Subversion (Apache). (You usually would set this variable to run
Wine or Winex on Red Hat 9)</li>
</ul>
<p>To use the NPTL version of Berkeley DB you also need to use a glibc
library with NPTL support, which probably means the i686 version. See
<a
href="http://svn.haxx.se/users/archive-2004-03/0488.shtml">
http://svn.haxx.se/users/archive-2004-03/0488.shtml
</a> for details.
</p>
</div>
<div class="h3" id="no-author" title="no-author">
<h3>Why does SVN log say "(no author)" for files
committed or imported via Apache (ra_dav)?</h3>
<p>If you allow anonymous write access to the repository via Apache,
the Apache server never challenges the SVN client for a username, and
instead permits the write operation without authentication. Since
Subversion has no idea who did the operation, this results in a log
like this:</p>
<blockquote><pre>
$ svn log
------------------------------------------------------------------------
rev 24:&nbsp; (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003)
</pre></blockquote>
<p>See the Subversion Book (<a
href="http://svnbook.red-bean.com/book.html#svn-ch-5-sect-4"
>"Networking a Repository"</a>)
to learn about configuring access restrictions in Apache.</p>
</div>
<div class="h3" id="windows-access-denied" title="windows-access-denied">
<h3>I'm getting occasional "Access Denied"
errors on Windows. They seem to happen at random. Why?</h3>
<p>These appear to be due to the various Windows services that monitor
the filesystem for changes (anti-virus software, indexing services, the
COM+ Event Notification Service). This is not really a bug in Subversion,
which makes it difficult for us to fix. A summary of the current state of
the investigation is available <a href=
"http://svn.haxx.se/dev/archive-2003-10/0136.shtml">here</a>.
A workaround that should reduce the incidence rate for most people was
implemented in revision 7598; if you have an earlier version, please
update to the latest release.
</p>
</div>
<div class="h3" id="freebsd-hang" title="freebsd-hang">
<h3>On FreeBSD, certain operations (especially
svnadmin create) sometimes hang. Why?</h3>
<p>This is usually due to a lack of available entropy on the system.
You probably need to configure the system to gather entropy from
sources such as hard-disk and network interrupts. Consult your system
manpages, specifically random(4) and rndcontrol(8) on how to effect
this change.</p>
</div>
<a name="301-error"></a> <!-- for compatibility with old
non-XML-name-compliant fragment id -->
<div class="h3" id="http-301-error" title="http-301-error">
<h3>I can see my repository in a web browser, but
'svn checkout' gives me an error about "301 Moved Permanently".
What's wrong?</h3>
<p>It means your httpd.conf is misconfigured. Usually this error happens
when you've defined the Subversion virtual "location" to exist within
two different scopes at the same time.</p>
<p>For example, if you've exported a repository as <tt>&lt;Location
/www/foo&gt;</tt>, but you've also set your <tt>DocumentRoot</tt> to
be <tt>/www</tt>, then you're in trouble. When the request comes in
for <tt>/www/foo/bar</tt>, apache doesn't know whether to find a
<i>real</i> file named <tt>/foo/bar</tt> within your
<tt>DocumentRoot</tt>, or whether to ask mod_dav_svn to fetch a file
<tt>/bar</tt> from the <tt>/www/foo</tt> repository. Usually the
former case wins, and hence the "Moved Permanently" error.</p>
<p>The solution is to make sure your repository
<tt>&lt;Location&gt;</tt> does <b>not</b> overlap or live within any
areas already exported as normal web shares.</p>
<p>It's also possible that you have an object in the web root
which has the same name as your repository URL. For example,
imagine your web server's document root is <tt>/var/www</tt>
and your Subversion repository is located at
<tt>/home/svn/repo</tt>. You then configure Apache to serve
the repository at <tt>http://localhost/myrepo</tt>. If you then
create the directory <tt>/var/www/myrepo/</tt> this will cause
a 301 error to occur.</p>
</div>
<div class="h3" id="no-copy-history" title="no-copy-history">
<h3>I'm trying to look at an old version of my
file, but svn says something about "path not found". What's going
on?</h3>
<p>A nice feature of Subversion is that the repository understands
copies and renames, and preserves the historical connections. For
example, if you copy <tt>/trunk</tt> to <tt>/branches/mybranch</tt>,
then the repository understands that every file in the branch has a
"predecessor" in the trunk. Running <tt>svn log --verbose</tt> will
show you the historical copy, so you can see the rename:</p>
<pre>
r7932 | joe | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line
Changed paths:
A /branches/mybranch (from /trunk:7931)
</pre>
<p>Unfortunately, while the repository is aware of copies and renames,
almost all the svn client subcommands are <b>not</b> aware. Commands
like <tt>svn diff</tt>, <tt>svn merge</tt>, and <tt>svn cat</tt> ought
to understand and follow renames, but don't yet do this. It's
scheduled as post-1.0 feature, currently <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=1093">issue
#1093</a>. For example, if you ask <tt>svn diff</tt> to compare two
earlier versions of <tt>/branches/mybranch/foo.c</tt>, the command
will not automatically understand that the task actually requires
comparing two versions of <tt>/trunk/foo.c</tt>, due to the rename.
Instead, you'll see an error about how the branch-path doesn't exist
in the earlier revisions.</p>
<p>The workaround for all problems of this sort is to do the legwork
yourself. That is: <i>you</i> need to be aware of any renamed paths,
discover them yourself using <tt>svn log -v</tt>, and then provide
them explicitly to the svn client. For example, instead of
running</p>
<pre>
$ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c
svn: Filesystem has no item
svn: '/branches/mybranch/fooc..c' not found in the repository at revision 1000
</pre>
...you would instead run
<pre>
$ svn diff -r1000:2000 http://host/repos/trunk/foo.c
...
</pre>
</div>
<div class="h3" id="digest-auth" title="digest-auth">
<h3>Why doesn't HTTP Digest auth work?</h3>
<p>This is probably due to a known bug in Apache HTTP Server (versions
2.0.48 and earlier), for which a patch is available, see
<a href="http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040"
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040</a>. You
may also want to read over
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1608"
>http://subversion.tigris.org/issues/show_bug.cgi?id=1608</a>
to see if the description there matches your symptoms.
</p>
</div>
<div class="h3" id="xlc-compile" title="xlc-compile">
<h3>Compiling with xlc on AIX, I get compilation
errors. What's wrong?</h3>
<p>Adding <tt>-qlanglvl=extended</tt> to the
environment variable CFLAGS for configuration and build
will make xlc a bit more flexible and the code should
compile without error. See
<a href="http://svn.haxx.se/dev/archive-2004-01/0922.shtml"
>http://svn.haxx.se/dev/archive-2004-01/0922.shtml</a> and
its associated thread for more details.
</p>
</div>
<div class="h3" id="nonrecursive-checkout" title="nonrecursive-checkout">
<h3>I checked out a directory non-recursively
(with -N), and now I want to make certain subdirectories
"appear". But <tt>svn up subdir</tt> doesn't work.</h3>
<p>See <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=695">issue
695</a>. The current implementation of <tt>svn checkout -N</tt> is
quite broken. It results in a working copy which has missing entries,
yet is ignorant of its "incompleteness". Apparently a whole bunch of
CVS users are fairly dependent on this paradigm, but none of the
Subversion developers were. For now, there's really no workaround
other than to change your process: try checking out separate
subdirectories of the repository and manually nesting your working
copies.</p>
</div>
<div class="h3" id="mod_dav_svn-win32" title="mod_dav_svn-win32">
<h3>I am trying to use mod_dav_svn
with Apache on Win32 and I'm getting an error saying that the
module cannot be found, yet the mod_dav_svn.so file is right
there in <tt>\Apache\modules.</tt></h3>
<p>The error message in this case is a little misleading. Most likely
Apache is unable to load one or more DLLs that <tt>mod_dav_svn.so</tt>
relies on. If Apache is running as a service it will not have the
same <tt>PATH</tt> as a regular user. Make sure that
<tt>libdb4*.dll</tt>, <tt>libeay32.dll</tt> and <tt>ssleay32.dll</tt>
are present in either <tt>\Apache\bin</tt> or
<tt>\Apache\modules</tt>. You can copy them from your Subversion
installation directory if they are not there.</p>
<p>If this still does not resolve the problem, you should use a tool
like <a href="http://www.dependencywalker.com">Dependency Walker</a>
on <tt>mod_dav_svn.so</tt> to see if there are any other unresolved
dependencies.</p>
</div>
<a name="win32-hooks"></a> <!-- for compatibility with old question -->
<a name="hook-environment"></a> <!-- for yet more compatibility with old question -->
<div class="h3" id="hook-debugging" title="hook-debugging">
<h3>Why aren't my repository hooks working?</h3>
<p>They're supposed to invoke external programs, but the invocations
never seem to happen.</p>
<p>Before Subversion calls a hook script, it removes <em>all</em>
variables -- including $PATH on Unix, and %PATH% on Windows
-- from the environment. Therefore, your script can only
run another program if you
spell out that program's absolute name.</p>
<p><b>Debugging tips:</b></p>
<p>
If you're using Linux or Unix, try running the script "by hand", by
following these steps:</p>
<ol>
<li>Use "su", "sudo", or something similar, to become the user who
normally would run the script. This might be <tt>httpd</tt> or
<tt>www-data</tt>, for example, if you're using Apache;
it might be a user like <tt>svn</tt> if you're running
svnserve and a special Subversion user exists. This
will make clear any permissions problems that the script
might have.
</li>
<li>
Invoke the script with an empty environment by using the
"env" program. Here's an
example for the post-commit hook:
<blockquote><pre>
$ env - ./post-commit /var/lib/svn-repos 1234
</pre></blockquote>
Note the first argument to "env" is a dash; that's what
ensures the environment is empty.
</li>
<li>
Check your console for errors.
</li>
</ol>
</div>
<div class="h3" id="diff-cmd" title="diff-cmd">
<h3>Why does my --diff-cmd complain about '-u'?
I tried to override it with --extensions, but it's not working.</h3>
<p>When using an external diff command, Subversion builds a fairly
complicated command line. First is the specified --diff-cmd. Next comes
the specified --extensions (although empty --extensions are ignored), or
'-u' if --extensions is unspecified (or specified as ''). Third and
fourth, Subversion passes a '-L' and the first file's label (e.g.
"project_issues.html (revision 11209)"). Fifth and sixth are another
'-L' and the second label. Seventh and eighth are the first and second
file names (e.g. ".svn/text-base/project_issues.html.svn-base" and
".svn/tmp/project_issues.html.tmp").</p>
<p>If your preferred diff command does not support these arguments, you
may need to create a small wrapper script to discard arguments and just
use the last couple file paths.</p>
<p>Warning: Beware that Subversion does not expect the external diff
program to change the files it receives, and doing so may scramble the
working copy.</p>
<p>For further information, see issue
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2044">#2044</a>.</p>
</div>
<div class="h3" id="plaintext-passwords" title="plaintext-passwords">
<h3>Ahhh! I just discovered that my
Subversion client is caching passwords in plain-text on disk!
AHHH!</h3>
<p>Calm down, take a deep breath.</p>
<p>On Windows 2000 or later, svn 1.2 and above uses standard
Windows APIs to encrypt the data, so only the user can decrypt the
cached password.</p>
<p>On Mac OS X, svn 1.4 and later uses the system Keychain
facility to encrypt/store your svn password.</p>
<p>On UNIX/Linux, there are no standard system encryption facilities,
so the password is stored in ~/.subversion/auth/. Notice, however,
that the directory which contains the cached passwords (usually
~/.subversion/auth/) has permissions of 700, meaning only you can read
them.</p>
<p>Trust your OS to protect data on disk.</p>
<p>However, if you're really worried, you can permanently turn off
password caching. With an svn 1.0 client, just set 'store-auth-creds
= no' in your run-time config file. With an svn 1.1 client or later,
you can use the more narrowly-defined 'store-passwords = no' (so that
server certs are still cached). More information on password cacheing
is in chapter 6 of the <a
href="http://svnbook.red-bean.com/nightly/en/index.html">"Nightly
Build" Subversion book</a>, under
<a href="http://svnbook.red-bean.com/nightly/en/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache">
"Client Credentials Caching".</a></p>
<p>Lastly, we point out that CVS has been caching passwords for years
in the .cvspass file. It may look like the passwords in .cvspass are
encrypted, but in fact they're only lightly scrambled with an
algorithm that's the moral equivalent to rot13. They can be cracked
instantly. The only utility of the scrambling is to prevent users
(like root) from accidentally seeing the password. Nobody's cared
enough to do this for Subversion yet; if you're interested, send
patches to the dev@ list.</p>
</div>
<div class="h3" id="bdb41-tabletype-bug" title="bdb41-tabletype-bug">
<h3>I'm getting the error "svn: bdb: call
implies an access method which is inconsistent with previous
calls". How do I fix this?</h3>
<p>Berkeley DB 4.1 has shown itself to be rather unstable - both 4.0
and 4.2 are better. This error message is a symptom of one unique way
in which 4.1 will sometimes break.</p>
<p>The problem is that the database format field for one of the tables
that make up a Subversion repository using the Berkeley DB backend has
become corrupted. For unknown reasons, this is almost always the
'copies' table, which switches from the 'btree' type to the 'recno'
type. Simple recovery procedures are outlined below - if they do not
succeed, you should contact the Subversion Users <a
href="mailto:users@subversion.tigris.org">mailing list</a>.</p>
<ul>
<li>Ensure that no other processes will attempt to access your
repository.</li>
<li>Now, <b>back up your repository</b> to a tar or zip file or
similar.</li>
<li>Change to the <tt>db</tt> subdirectory of your repository.</li>
<li><tt>rm __db.* log.*</tt></li>
<li><tt>db_dump -p -r copies &gt; copies.dump</tt></li>
<li>Now edit <tt>copies.dump</tt>. In the section near the top,
change "<tt>type=recno</tt>" to "<tt>type=btree</tt>", and delete
the line beginning "<tt>re_len=</tt>".</li>
<li><tt>rm copies</tt></li>
<li><tt>db_load copies &lt; copies.dump</tt></li>
<li><tt>svnadmin dump .. &gt; ../../my-recovered.svndump</tt></li>
<li>Now create a new repository, reload the dump file just produced,
and copy across any custom hooks or configuration. Verify that the
highest revision number in the new repository is what you think it
should be.</li>
</ul>
</div>
<div class="h3" id="hotcopy-large-repos" title="hotcopy-large-repos">
<h3>I can't hotbackup my repository,
svnadmin fails on files larger than 2Gb!</h3>
<p>Early versions of APR on its 0.9 branch, which Apache 2.0.x and
Subversion 1.x use, have no support for copying large files (2Gb+).
A fix which solves the 'svnadmin hotcopy' problem has been applied and
is included in APR 0.9.5+ and Apache 2.0.50+. The fix doesn't work
on all platforms, but works on Linux.
</p>
</div>
<div class="h3" id="hidden-log" title="hidden-log">
<h3>I cannot see the log entry for the file
I just committed. Why?</h3>
<p>Assume you run '<tt>svn&nbsp;checkout</tt>' on a repository and
receive a working copy at revision 7 (aka, r7) with one file in it
called <tt>foo.c</tt>. You modify the file and commit it
successfully. Two things happen:</p>
<ul>
<li>The repository moves to r8 on the server.</li>
<li>In your working copy, only the file <tt>foo.c</tt> moves to r8.
The rest of your working copy remains at r7.</li>
</ul>
<p>You now have what is known as a <i>mixed revision working copy</i>.
One file is at r8, but all other files remain at r7 until they too are
committed, or until '<tt>svn&nbsp;update</tt>' is run.</p>
<pre> $ svn -v status
7 7 nesscg .
8 8 nesscg foo.c
$</pre>
<p>If you run the '<tt>svn&nbsp;log</tt>' command without any
arguments, it prints the log information for the current directory
(named '<tt>.</tt>' in the above listing). Since the directory itself
is still at r7, you do not see the log information for r8.</p>
<p>To see the latest logs, do one of the following:</p>
<ol>
<li>Run '<tt>svn&nbsp;log&nbsp;-rHEAD</tt>'.</li>
<li>Run '<tt>svn&nbsp;log&nbsp;URL</tt>', where URL is the repository URL.</li>
<li>Ask for just that file's log information, by running
'<tt>svn&nbsp;log&nbsp;foo.c</tt>'.</li>
<li>Update your working copy so it's all at r8, then run
'<tt>svn&nbsp;log</tt>'.</li>
</ol>
</div>
<div class="h3" id="bdb43-upgrade" title="bdb43-upgrade">
<h3>After upgrading to Berkeley DB
4.3 or later, I'm seeing repository errors.</h3>
<p>Prior to Berkeley DB 4.3, <tt>svnadmin recover</tt> worked to upgrade a
Berkeley DB repository in-place. However, due to a change in the behaviour
of Berkeley DB in version 4.3, this now fails.</p>
<p>Use this procedure to upgrade your repository in-place to Berkeley
DB 4.3 or later:</p>
<ul>
<li>Make sure no process is accessing the repository (stop
Apache, svnserve, restrict access via file://, svnlook, svnadmin,
etc.)</li>
<li>Using an <i>older</i> <tt>svnadmin</tt> binary (that is, linked to
an older Berkeley DB):
<ol>
<li>Recover the
repository: '<tt>svnadmin&nbsp;recover&nbsp;/path/to/repository</tt>'</li>
<li>Make a backup of the repository.</li>
<li>Delete all unused log files. You can see them by running
'<tt>svnadmin&nbsp;list-unused-dblogs&nbsp;/path/to/repeository</tt>'</li>
<li>Delete the shared-memory files. These are files in the
repository's <tt>db/</tt> directory, of the form <tt>__db.00*</tt></li>
</ol>
</li>
</ul>
<p>The repository is now usable by Berkeley DB 4.3.</p>
</div>
<div class="h3" id="tiger-apr-0.9.6" title="tiger-apr-0.9.6">
<h3>Why do I get occasional, seemingly inconsistent errors when checking
out over http:// from a repository running on MacOS X 10.4 (Tiger)?</h3>
<p>Note: this assumes the repository is being served by Apache 2.0.x.</p>
<p>There is <a href="http://issues.apache.org/bugzilla/show_bug.cgi?id=34332"
>a bug in APR 0.9.6</a> that is present when it is running on Tiger,
and shows up when you attempt to check out a file larger than 64Kb.
The resulting checkout fails, often with unpredictable error messages.
Here are some examples of what you might see on the client side, the
specific errors may differ for you:</p>
<pre>
svn: Invalid diff stream: [tgt] insn 1 starts beyond the target view position
</pre>
<pre>
svn: Unexpected end of svndiff input
</pre>
<pre>
svn: REPORT request failed on '/path/to/repository'
svn: REPORT of '/path/to/repository/!svn/vcc/default': Chunk delimiter was invalid
</pre>
<p>There may also be errors in the Apache error_log, such as:</p>
<pre>
[error] Provider encountered an error while streaming a REPORT response. [500, #0]
[error] A failure occurred while driving the update report editor [500, #190004]
</pre>
<p>To confirm the presence of this bug &nbsp;&mdash;&nbsp; assuming
you have access to the machine that the repository is being served
from &nbsp;&mdash;&nbsp; try checking out using a file:// URL, which
will access the filesystem directly instead of going through Apache.
If the resulting checkout completes successfully, then it is almost
certain that this is the problem.</p>
<p>Currently, the best solution is to upgrade to APR 1.2.0+.</p>
<p>Alternately, you can rebuild Apache and Subversion from their
respective sources, setting the following environment variable before
running configure for Apache:</p>
<pre>
setenv ac_cv_func_poll no
</pre>
<p>or in Bourne shell syntax, like this:</p>
<pre>
ac_cv_func_poll=no; export ac_cv_func_poll
</pre>
<p>If you built APR / APRUTIL separately (i.e., you did not use the
ones that come as part of the Apache tarball), you must set that
environment variable before running configure for APR, as this is
where the problem lies.</p>
</div>
<div class="h3" id="debian-libtool" title="debian-libtool">
<h3>I can't build Subversion from working copy
source on Debian GNU/Linux; I get errors at the final link
stage. What's wrong?</h3>
<p>If you see errors like this in the final link stage of a Subversion
trunk source build:</p>
<pre>
/usr/local/apache2/lib/libaprutil-0.so.0: undefined reference to `db_create'
/usr/local/apache2/lib/libaprutil-0.so.0: undefined reference to `db_strerror'
</pre>
<p>it might be because you're on a Debian GNU/Linux system and need to
upgrade 'libtool'. (I've also heard that the Debian packagers had to
tweak 'libtool' and that this may cause some problems for Subversion
builds. But that's hearsay&nbsp;&mdash;&nbsp;I didn't have time to
verify the details before writing this FAQ entry. However, see <a
href="http://subversion.tigris.org/servlets/ReadMsg?list=dev&amp;msgNo=112617"
>http://subversion.tigris.org/servlets/ReadMsg?list=dev&amp;msgNo=112617</a>
and the <a
href="http://subversion.tigris.org/servlets/BrowseList?list=dev&amp;by=thread&amp;from=435265"
>thread</a> it spawned for a detailed discussion.)</p>
<p>In any case, after encountering this problem on a Debian GNU/Linux
system running a newly-dist-upgraded 'testing' distribution on 15 Nov
2005, the solution was to build <a
href="http://www.gnu.org/software/libtool/libtool.html">libtool&nbsp;1.5.20</a>
from source, using the standard "./configure &amp;&amp; make &amp;&amp;
sudo&nbsp;make&nbsp;install" recipe. After that, I did a 'make&nbsp;clean' in
my Subversion working copy tree, './autogen.sh', './configure', 'make',
and everything worked fine.</p>
<p>Note that another report of these symptoms appeared at <a
href="http://svn.haxx.se/dev/archive-2003-01/1125.shtml"
>http://svn.haxx.se/dev/archive-2003-01/1125.shtml</a>, though the
solution described here was not mentioned in that thread.</p>
</div>
<div class="h3" id="freebsd-listen-host" title="freebsd-listen-host">
<h3>I'm using FreeBSD, and I've started svnserve, but it doesn't seem
to be listening on port 3690.</h3>
<p>Short answer: invoke <tt>svnserve</tt> with
the <tt>--listen-host=0.0.0.0</tt> option.</p>
<p>Slightly longer answer: FreeBSD daemons only listen on tcp6 by
default; that option tells them to also listen on tcp4.</p>
</div>
<div class="h3" id="already-under-version-control" title="already-under-version-control">
<h3>I can't add a directory
because Subversion says it's "already under version control".</h3>
<p>The directory you're trying to add already contains
a <tt>.svn</tt> subdirectory, but it's from a different repository
than the directory to which you're trying to add it. This probably
happened because you used your operating system's "copy" command to
copy one working copy into the current one.</p>
<p>
The quick and dirty solution is to delete all <tt>.svn</tt>
directories contained in the directory you're trying to add; this
will let the "add" command complete. If you're using Unix, this
command will delete <tt>.svn</tt> directories
under <tt>dir</tt>:</p>
<pre>
find dir -type d -name .svn -exec rm -rf {} \;
</pre>
<p>However, you should ask yourself <em>why</em> you made this copy;
and you should ensure that by adding this directory, you won't be
making an unwanted copy of it in your repository.
</p>
</div>
<div class="h3" id="slow-private-svnserve" title="slow-private-svnserve">
<h3>Accessing non-public repositories
via svnserve is really slow sometimes.</h3>
<p>This often happens when APR is compiled to use <tt>/dev/random</tt>
and the server is unable to gather enough entropy. If Subversion is the
only application using APR on the server, you can safely recompile APR
with the <tt>--with-devrandom=/dev/urandom</tt> option passed to
<tt>configure</tt>. This should <b>not</b> be done on systems that use
APR for other processes, however, as it could make other services
insecure.</p>
</div>
<div class="h3" id="ssl-negotiation-error" title="ssl-negotiation-error">
<h3>When performing Subversion operations involving a lot of data over
SSL, I get the error <tt>SSL negotiation failed: SSL error:
decryption failed or bad record mac</tt>.</h3>
<p>This can occur due to a problem with OpenSSL 0.9.8. Downgrading to
an older version (or possibly upgrading to a newer version) is known
to fix this issue.</p>
</div>
<div class="h3" id="broken-subclipse" title="broken-subclipse">
<h3>I get an error that says "This client is too old".</h3>
You're using both an older (pre-1.4) version of the Subversion
command-line client, and Subclipse. You recently upgraded Subclipse,
and now your command-line client says
<pre>
svn: This client is too old to work with working copy
'/path/to/your/working/copy'; please get a newer Subversion client
</pre>
This happened because Subversion's working-copy format changed
incompatibly&mdash;the new version of Subclipse upgraded your working
copy, so now your command-line program, which is old, cannot read it.
(This problem isn't specific to Subclipse; it would also have happened
if you'd used a command-line client that was 1.4 or newer, along with
your older command-line client.)
The fix is simply to upgrade your command-line client to 1.4 or newer.
</div>
<div class="h3" id="switch-problems" title="switch-problems">
<h3>Why doesn't <tt>svn switch</tt> work in some cases?</h3>
<p>In some cases where there are unversioned (and maybe ignored) items
in the working copy, <tt>svn switch</tt> can get an error. The switch
stops, leaving the working copy half-switched.</p>
<p>Unfortunately, if you take the wrong corrective action you can end
up with an unusable working copy. Sometimes with these situations,
the user is directed to do <tt>svn cleanup</tt>. But the <tt>svn
cleanup</tt> may also encounter an error. See <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=2505">issue
#2505</a>.</p>
<p>The user can manually remove the directories or files causing
the problem, and then run <tt>svn cleanup</tt>, and continue the switch, to
recover from this situation.</p>
<p>Note that a switch from a <i>pristine</i> clean checkout always
works without error. There are three ways of working if you are using
<tt>svn switch</tt> as part of your development process:</p>
<ol>
<li>Fully clean your working copy of unversioned (including ignored)
files before switching. <br/><b>WARNING! This deletes all unversioned
dirs/files. Be VERY sure that you do not need anything that will be
removed.</b>
<blockquote>
<div><pre><code>
# Check and delete svn unversioned files:
svn status --no-ignore | grep '^[I?]' | sed 's/^[I?]//'
svn status --no-ignore | grep '^[I?]' | sed 's/^[I?]//' | xargs rm -rf
</code></pre></div>
</blockquote>
</li>
<li>Keep a <i>pristine</i> clean checkout. Update that, then copy it,
and switch the copy when a switch to another branch is desired.</li>
<li>Live dangerously :).
Switch between branches without cleaning up BUT if you encounter a switch error
know that you have to recover from this properly.
Delete the unversioned files and the directory that the error was reported on.
Then "svn cleanup" if needed and then resume the switch.
Unless you delete <em>all</em> unversioned files, you may have to repeat this
process multiple times.</li>
</ol>
<p>Some examples are detailed
<a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2505">here in issue 2505</a>.
The problem is that the svn client plays it
safe and doesn't want to delete anything unversioned.
</p>
<p>Two specific examples are detailed here to illustrate a problem like this.
There are also other svn switch errors, not covered here, which you
can avoid by switching only from a <em>pristine</em> checkout.</p>
<ol>
<li>If any directory has been moved or renamed between the branches, then
anything unversioned will cause a problem.
In this case, you'll see this error:
<br/>
<blockquote>
<div><pre><code>
wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
svn: Won't delete locally modified directory '&lt;dir&gt;'
svn: Left locally modified or unversioned files
</code></pre></div>
</blockquote>
<p>Removing all unversioned files, and continuing the switch will recover from this.</p>
</li>
<li>If a temporary build file has ever been added and removed, then a switch
in a repository with that unversioned file (likely after a build) fails.
You'll see the same error:
<blockquote>
<div><pre><code>
wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
svn: Won't delete locally modified directory '&lt;dir&gt;'
svn: Left locally modified or unversioned files
</code></pre></div>
</blockquote>
<p>In this case, just removing the unversioned items will not recover.
A cleanup fails, but svnswitch directs you to run "svn cleanup".</p>
<blockquote>
<div><pre><code>
wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
svn: Directory '&lt;dir&gt;/.svn' containing working copy admin area is missing
wc/$ svn cleanup
svn: '&lt;dir&gt;' is not a working copy directory
wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx
svn: Working copy '.' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
</code></pre></div>
</blockquote>
<p>Removing the directory (and all other unversioned files, to prevent
"switch" from breaking on a similar error repeatedly), and continuing the switch
will recover from this.</p>
</li>
</ol>
<p>The TortoiseSVN cleanup error is a bit different. You might encounter this:
</p>
<blockquote>
<div><pre><code>
Subversion reported an error while doing a cleanup!
&lt;dir&gt;/&lt;anotherdir&gt; is not a working copy directory
</code></pre></div>
</blockquote>
<p>In each case here, the "svn switch" breaks leaving you with a half-switched
working copy. "svn status" will show items with S for switched items (different
from top directory), ! for directories with problems, and ~ for the files that are
the problem (and with maybe L for locked). Like this:</p>
<blockquote>
<div><pre><code>
wc/$ svn status
! .
! &lt;dir&gt;
S &lt;switched_things&gt;
~ &lt;dir&gt;/&lt;thing_that_is_now_unversioned&gt;
</code></pre></div>
</blockquote>
</div>
<div class="h3" id="long-paths" title="long-paths">
<h3>In Windows, when doing an update with the command-line client, I
get an error saying "The system cannot find the path specified"
and suggesting that my working copy might be corrupt. But I can
update with TortoiseSVN just fine. What's going on?</h3>
<p>A careful examination of the Windows API documentation regarding <a
href="http://msdn2.microsoft.com/en-us/library/aa365247.aspx#maximum_path_length"
>Naming a File</a> reveals the most common reason why this happens. In
short, you can address significantly longer path names when using the
Unicode versions of the Windows path functions, and providing absolute
path specifiers instead of relative path specifiers. Fortunately, the
Apache Portable Runtime (APR) library that Subversion uses
transparently converts absolute paths (like
<tt>C:\WorkingCopy\file.txt</tt>) into the form required by the
Windows APIs (<tt>\\?\C:\WorkingCopy\file.txt</tt>), and back again.
<em>Unfortunately</em>, you only get these long-path benefits when
using absolute paths.</p>
<p>To see if path length is the reason for the problem you're seeing,
try providing an absolute target path to the Subversion command-line
client instead of a relative one (or none at all). In other words,
instead of doing this:</p>
<blockquote>
<div><pre><code>
C:\> svn up WorkingCopy
</code></pre></div>
</blockquote>
<p>or this:</p>
<blockquote>
<div><pre><code>
C:\> cd C:\WorkingCopy
C:\WorkingCopy> svn up
</code></pre></div>
</blockquote>
<p>do this:</p>
<blockquote>
<div><pre><code>
C:\> svn update C:\WorkingCopy
</code></pre></div>
</blockquote>
<p>If the problem goes away, congratulations &mdash; you've hit a
Windows path length limitation. And now you know the workaround.</p>
<p><strong>Why does this problem not affect TortoiseSVN?</strong>
Because TortoiseSVN <em>always</em> provides absolute paths to the
Subversion APIs.</p>
<p><strong>Why, then, does the Subversion command-line client not
always convert its input into absolute paths and use those?</strong>
The Subversion developers have been operating under the principle
that, for reasons of user experience, the display of paths in the
tool's output should match the syntax of the paths provided as input.
And while conversion to an absolute path from a relative one is a
fairly trivial operation, the reverse transformation is fraught with
complexities. (In other words, it's a hard problem not high on our
priority list.)</p>
</div>
<div class="h3"
id="working-copy-format-change" title="working-copy-format-change">
<h3>I got an error saying "This client is too old to work with working
copy '...' ". How can I fix it without upgrading Subversion?</h3>
<p>Sometimes the working copy metadata format changes incompatibly
between minor releases. For example, say you have a working copy
created with Subversion 1.4.4, but one day you decide to try out
Subversion 1.5.0. Afterwards, you attempt to switch back to 1.4.4,
but it doesn't work&nbsp;&mdash;&nbsp;it just gives the above
error.</p>
<p>This is because 1.5.0 upgraded your working copy format to support
some new features (in this case, changelists, the keep-local flag, and
variable-depth directories). Although 1.4.4 doesn't know anything
about these new features, it can at least recognize that the working
copy format has been upgraded to something higher than it can
handle.</p>
<p>1.5.0 upgraded the working copy for a good reason: it realizes that
1.4.4 does not know about these new features, and that if 1.4.4 were
to meddle with the working copy metadata now, important information
might be lost, possibly causing corruption (see <a
href="http://subversion.tigris.org/issues/show_bug.cgi?id=2961" >issue
#2961</a>, for example).</p>
<p>But this automatic upgrade behavior can be annoying, if you just
want to try out a new release of Subversion without installing it
permanently. For this reason, we distribute a script that can
downgrade working copies when doing so is safe:</p>
<blockquote>
<p><a
href="http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py"
>http://svn.collab.net/repos/svn/trunk/tools/client-side/change-svn-wc-format.py</a></p>
</blockquote>
<p>Run that script with the "<tt>--help</tt>" option to see how to use
it. As future versions of Subversion are released, we will try to
keep this FAQ entry up-to-date with potential downgrade scenarios and
their implications.</p>
</div>
</div>
<div class="h2" id="developer-questions" title="developer-questions">
<h2>Developer questions:</h2>
<p/>
<div class="h3" id="ramdisk-tests" title="ramdisk-tests">
<h3>How do I run the regression tests in a
RAM disk?</h3>
<p>Test execution can be dramatically sped up by keeping Subversion
test data on a RAM disk. On a Linux system, you can mount a RAM disk
on the fly with the command:</p>
<blockquote>
<div><code>mount -t tmpfs tmpfs
/path/to/src/subversion/tests/cmdline/svn-test-work
-o uid=$USER,mode=770,size=32m</code></div>
</blockquote>
<p>Or, for a more permanent solution, add lines like the following in
your <code>/etc/fstab</code> file:</p>
<blockquote>
<div><code>tmpfs /path/to/src/svn/subversion/tests/cmdline/svn-test-work
tmpfs defaults,user,noauto,exec,size=32m</code></div>
</blockquote>
<p>The minimum required size for testing ramdisk is approximately 700MB.
However, flagging your test targets for cleanup dramatically reduces
the space requirements (as shown in the example configuration above),
and thus your memory usage. Cleanup means more I/O, but since test
data is in-memory, there will be no performance degradation. Example:</p>
<blockquote><div><code>
make check CLEANUP=true
</code></div></blockquote>
<p>See <a href="http://svn.haxx.se/dev/archive-2003-02/0068.shtml"
>http://svn.haxx.se/dev/archive-2003-02/0068.shtml</a> for the
original authoritative discussion on use of RAM disks.</p>
</div>
<div class="h3" id="dynamic-exe-debugging" title="dynamic-exe-debugging">
<h3>How do I run a debugger on dynamic Subversion binaries without
having to install them?</h3>
<p>Before the <code>make install</code> step on unix-y systems,
dynamically built "executables" in a Subversion source tree are
actually libtool-generated shell scripts which re-link and run the
real binary. As shown below, this complicates debugging:</p>
<blockquote>
<div><code>subversion$ gdb subversion/svn/svn</code></div>
<div><code>... "/path/to/subversion/subversion/svn/svn": not in
executable format: File format not recognized</code></div>
</blockquote>
<p>While this can be worked around by building using the
<code>--disable-shared</code> argument to configure to statically link
the binaries, or installing them and pointing your debugger at the
installed version, it's often necessary or more expedient to be able
to debug them right within your source tree.</p>
<p>To do so, edit the last <code>exec</code> statement in the shell
script to run the real binary in your debugger. With gdb, this
amounts to replacing <code>exec "$progdir/$progname"</code> with
<code>exec gdb --args "$progdir/$progname"</code>.</p>
<p>This trick is also very useful when applied to the
libtool-generated shell scripts for the white box tests.</p>
</div>
<div class="h3" id="avoiding-compiler-inlining"
title="avoiding-compiler-inlining">
<h3>How do I run a debugger on Subversion binaries without compiler
inlining obfuscating the source?</h3>
<p>By default, gcc will often optimize away private variables and
functions, inlining the associated operations. This can complicate
stepping through the code in a debugger.</p>
<p>Work around this by turning off optimization during the
<code>make</code> step on unix-y systems:</p>
<blockquote>
<div><code>subversion$ make EXTRA_CFLAGS=-O0</code></div>
</blockquote>
<p>(That's "dash ohh zero".) Alternately, you can make this change
more permanent by running <code>configure</code> as follows:</p>
<blockquote>
<div><code>subversion$ ./configure --enable-debug</code></div>
</blockquote>
<p>For a production install, remember to undo this operation before
installing Subversion from source, by re-running <code>make</code> or
<code>configure</code> without the extra flag.</p>
</div>
</div>
<div class="h2" id="references" title="references">
<h2>References:</h2>
<p/>
<div class="h3" id="http-methods" title="http-methods">
<h3>What are all the HTTP methods Subversion
uses?</h3>
<p>The Subversion client speaks a subset the WebDAV/DeltaV protocol to
the mod_dav_svn server module. The short answer is:</p>
<pre>
OPTIONS, PROPFIND, GET, REPORT,
MKACTIVITY, PROPPATCH, PUT, CHECKOUT, MKCOL,
MOVE, COPY, DELETE, LOCK, UNLOCK, MERGE
</pre>
<p>The details of the protocol are documented here:</p>
<a href="http://svn.collab.net/repos/svn/trunk/notes/webdav-protocol">http://svn.collab.net/repos/svn/trunk/notes/webdav-protocol</a>
</div>
<div class="h3" id="bikeshed" title="bikeshed">
<h3>What's a 'bikeshed'?</h3>
<p>See Poul-Henning Kamp's post to freebsd-hackers: <a href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING">http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING</a>.
</p>
</div>
<div class="h3" id="pronounce" title="pronounce">
<h3>How do you pronounce "Subversion"?</h3>
<p>Jim Blandy, who gave Subversion both its name and repository
design, pronounces "Subversion" <a href="http://svn.collab.net/repos/svn-committers/trunk/sounds/pronunciation/index.html">"Subversion"</a>.
</p>
</div>
<div class="h3" id="baton" title="baton">
<h3>What's a 'baton'?</h3>
<p>Throughout Subversion's source code there are many references to
'baton' objects. These are just <tt>void *</tt> datastructures that
provide context to a function. In other APIs, they're often called
<tt>void *ctx</tt> or <tt>void *userdata</tt> Subversion
developers call the structures "batons" because they're passed around
quite a bit.</p>
</div>
<div class="h3" id="def-wedged-repository" title="def-wedged-repository">
<h3>What do you mean when you say that
repository is 'wedged'?</h3>
<p>wedged repository:</p>
<blockquote>
<p>A Subversion repository consists of two different internal parts, a
working compartment and a storage compartment. A wedged repository is
a repository where the working compartment is unaccessible for some
reason, but the storage compartment is intact. Therefore, a wedged
repository has not suffered any loss of data, but the working
compartment has to be corrected before you can access the
repository. See <a href="#stuck-bdb-repos">this</a> entry for details
how to do that.</p>
</blockquote>
<p>corrupted repository:</p>
<blockquote>
<p>A corrupted Subversion repository is a repository where the storage
compartment has been damaged, and therefore there is some degree of
real data loss in the repository.</p>
</blockquote>
<p>You might also like to check The Jargon File's definition for
<a href="http://catb.org/~esr/jargon/html/W/wedged.html">'wedged'</a>.
</p>
</div>
</div>
</div>
</body>
</html>