CINXE.COM

<!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta http-equiv="x-ua-compatible" content="ie=edge"> <title>Apache Subversion FAQ</title> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <link rel="manifest" href="/site.webmanifest"> <link rel="apple-touch-icon" href="/icon.png"> <link rel="icon" type="image/png" href="/icon.png"> <link rel="stylesheet" href="/style/site.css" type="text/css" media="all"> <meta name="theme-color" content="#98b0d4"> </head> <body> <div id="site-banner"> <div style="font-style: italic; text-align: center;" id="site-banner-apachelogo"> <a href="https://www.apache.org/" ><img src="/images/asf_logo_wide.svg" alt="Apache Software Foundation" /></a> </div> <a href="/"> <img src="/images/svn-name-banner.svg" width="379" height="80" alt="[S] Subversion" id="site-banner-svnlogo" /></a> </div>  <div id="site-nav"> <label for="hamburger">☰</label> <input type="checkbox" id="hamburger"/> <nav id="site-nav-menu"> <p>About Subversion <ul> <li><a href="/news.html">News</a></li> <li><a href="/features.html">Features</a></li> <li><a href="/docs/">Documentation</a></li> <li><a href="/faq.html">FAQ</a></li> <li><a href="/roadmap.html">Roadmap</a></li> <li><a href="/security/">Security</a></li> <li><a href="/quick-start">Quick Start</a></li> <li><a href="/blog/">Blog</a></li> </ul> </p> <p>Getting Subversion <ul> <li><a href="/packages.html">Binary Packages</a></li> <li><a href="/download.cgi">Source Download</a></li> <li><a href="/docs/release-notes/">Release Notes</a></li> </ul> </p> <p>Community <ul> <li><a href="/mailing-lists.html">Mailing Lists</a></li> <li><a href="/reporting-issues.html">Reporting Issues</a></li> <li><a href="https://cwiki.apache.org/confluence/display/SVN/">Wiki</a></li> <li><a href="/contributing.html">Getting Involved</a></li> <li><a href="/source-code.html">Source Code</a></li> </ul> </p> <p>About the <acronym title="Apache Software Foundation">ASF</acronym> <ul> <li><a class="linkaway" href="https://www.apache.org/licenses/">License</a></li> <li><a class="linkaway" href="https://www.apache.org/foundation/sponsorship.html">Donate</a></li> <li><a class="linkaway" href="https://www.apache.org/foundation/thanks.html">Thanks</a></li> </ul> </p> <p id="site-search"> <form action="https://www.google.com/search" method="get" style="margin-top: 10px; margin-bottom: 10px; display: inline;"> <div style="display: inline;"> <input value="subversion.apache.org" name="sitesearch" type="hidden" /> <input name="q" id="query" type="text" placeholder="Search..." style="width: 10em" /> <input name="Search" value="Go" type="submit"/> </div> </form> </p>  <p id="site-apachecon-block"> <p><a href="https://www.apache.org/events/current-event.html" ><img src="https://www.apache.org/events/current-event-125x125.png" alt="ApacheCon" /></a></p> </p>  <p id="site-svnbook-block"> <p>Read the official Subversion documentation <a href="https://svnbook.red-bean.com/" class="linkaway nopadding">online</a>!</p> <p><a href="https://svnbook.red-bean.com/" ><img src="/images/svnbook-cover.jpg" alt="Version Control With Subversion"/></a></p> </p>  <p id="copyright"> <p>Copyright © 2023 <a href="https://www.apache.org/" class="nopadding">The Apache Software Foundation</a>, Licensed under the <a href="https://www.apache.org/licenses/LICENSE-2.0" class="nopadding">Apache License, Version 2.0</a>. Apache, Apache Subversion, and the Apache feather logo are trademarks of The Apache Software Foundation. Subversion and the Apache Subversion logo are registered trademarks of The Apache Software Foundation.</p> <p><a href="https://privacy.apache.org/policies/privacy-policy-public.html" class="nopadding">Privacy policy</a></p> </p>  </nav> </div>  <div id="site-content"> <div id="site-notice">  </div>  <h1>Apache Subversion FAQ</h1> <p>Translations: <a href="faq.ja.html">日本語</a>, <a href="faq.zh.html">简体中文</a></p> <p>These are the questions related to the currently <a href="/docs/release-notes/#supported-versions">supported versions</a>. For older questions, see <a href="#deprecated-faq">below</a>.</p> <div class="h2"> <h2>Table of Contents</h2> <h4>General questions:</h4> <ul> <li><a href="#why">What is Subversion? Why does it exist?</a></li> <li><a href="#collab">Is Subversion proprietary software?</a></li> <li><a href="#stable">How stable is Subversion?</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> <li><a href="#irc">Where are the IRC channels?</a></li> <li><a href="#dst-2007">How is Subversion affected by changes in Daylight Savings Time (DST)?</a></li> <li><a href="#shattered-sha1">How is Subversion affected by SHA-1 hash collisions?</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="#reverseproxy">I need to put Subversion behind a reverse 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="#reposperms">How do I set repository permissions correctly?</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="#fix-nonLF-log">What can I do about <tt>"svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property"</tt> while running 'svnadmin load'?</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="#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> <li><a href="#undo">How do I make the contents of a previous revision become HEAD again?</a></li> </ul> <h4>Troubleshooting:</h4> <ul> <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 line 38: Unterminated `s' 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">Microsoft Visual Studio 2002 and 2003 seems to have a problem with the ".svn" directory name. What should I do?</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="#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="#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">How does Subversion cache credentials (plaintext and encrypted)</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="#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="#svnserve-listen-host">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> <li><a href="#relocation-against-local-symbol">I got an error saying "relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object" when building the Neon library on 64-bit Linux.</a></li> <li><a href="#secure-connection-truncated">Why am I getting an error saying "Could not read response body: Secure connection truncated" when doing a checkout from Apache?</a></li> <li><a href="#self-tree-conflict">Why am I getting a tree conflict upon update even though no one else has committed conflicting changes?</a></li> <li><a href="#ssl-error-336032856">When performing Subversion operations over SSL, I get the error <tt>SSL handshake failed: SSL error code -1/1/336032856</tt></a></li> <li><a href="#error-validating-server-certificate">I get <tt>Error validating server certificate</tt> error even though SSL certificates are correctly on the server-side</a></li> <li><a href="#where-are-the-files">After importing files to my repository, I don't see them in the repository directory. Where are they?</a></li> <li><a href="#copy-mergeinfo">When does <tt>svn copy</tt> create <tt>svn:mergeinfo</tt> properties?</a></li> <li><a href="#password-encodings">Passwords which contain some special characters do not seem to be working?</a></li> <li><a href="#dav-slow-copy">Why does an HTTP(S) URL-to-URL copy or branch/tag operation take a long time?</a></li> <li><a href="#ssl-communication-error">When performing Subversion operations over SSL, I get the error <tt>An error occurred during SSL communication</tt></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> <li><a href="#cvssv3">What is CVSSv3 and what do the score and vector mean?</a></li> </ul> </div> <hr/> <div class="h2" id="general-questions"> <h2>General questions: <a class="sectionlink" href="#general-questions" title="Link to this section">¶</a> </h2> <div class="h3" id="why"> <h3>What is Subversion? Why does it exist? <a class="sectionlink" href="#why" title="Link to this section">¶</a> </h3> <p>Subversion is an open-source, centralized version control system. See <a href="/index.html#vision">Our Vision</a> on our front page to know why Subversion exists. Want to take a quick look? See <a href="/quick-start">Quick Start</a>.</p> </div> <div class="h3" id="collab"> <h3>Is Subversion proprietary software? <a class="sectionlink" href="#collab" title="Link to this section">¶</a> </h3> <p>No, Subversion is open source / free software. Several companies (CollabNet, WANdisco, VisualSVN, elego, ...) pay or have paid the salaries of some full-time developers, but the software carries an <a href="https://www.apache.org/licenses/LICENSE-2.0" >Apache License</a> which is fully compliant with the <a href="https://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 any company or any person is required.</p> </div> <div class="h3" id="stable"> <h3>How stable is Subversion? <a class="sectionlink" href="#stable" title="Link to this section">¶</a> </h3> <p>Subversion is very stable. It is mature software, with strong <a href="#interop">compatibility guarantees</a>. The Subversion development community cares deeply about its stability and robustness.</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"> <h3>What is Subversion's client/server interoperability policy? <a class="sectionlink" href="#interop" title="Link to this section">¶</a> </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. Such limitations are always documented in the <a href="/docs/release-notes/">release notes</a> of our releases.</p> <p>Our client/server interoperability policy is documented in the "Compatibility" section of the <a href="/docs/community-guide/">Subversion Community Guide</a>.</p> </div> <div class="h3" id="portability"> <h3>What operating systems does Subversion run on? <a class="sectionlink" href="#portability" title="Link to this section">¶</a> </h3> <p>All modern flavors of Unix, Windows, BeOS, OS/2, macOS.</p> <p>Subversion is written in ANSI C and uses APR, the <a href="https://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"> <h3>What's all this about a new filesystem? Is it like ext2? <a class="sectionlink" href="#filesystem" title="Link to this section">¶</a> </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"> <h3>What kind of hardware do I need to run a Subversion server? <a class="sectionlink" href="#server-requirements" title="Link to this section">¶</a> </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.</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"> <h3>I heard that Subversion is an Apache extension? What does it use for servers? <a class="sectionlink" href="#apache-extension" title="Link to this section">¶</a> </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/nightly/en/svn.serverconfig.html" >chapter 6</a> in the Subversion book to learn more.</p> </div> <div class="h3" id="need-apache"> <h3>Does this mean I have to set up Apache to use Subversion? <a class="sectionlink" href="#need-apache" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.serverconfig.html" >chapter 6</a> in the Subversion book.</p> </div> <div class="h3" id="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? <a class="sectionlink" href="#multiple-apachim" title="Link to this section">¶</a> </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 80</tt>" to "<tt>Listen 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"> <h3>Why don't you do X, just like SCM system Y? <a class="sectionlink" href="#feature-x" title="Link to this section">¶</a> </h3> <p>Subversion is not attempting to imitate all the features of every SCM system out there. See <a href="/index.html#vision" >Our Vision</a>.</p> </div> <div class="h3" id="globalrev"> <h3>Why does the entire repository share the same revision number? I want each of my projects to have their own revision numbers. <a class="sectionlink" href="#globalrev" title="Link to this section">¶</a> </h3> <p>First, note that Subversion has no concept of projects. The repository just stores a versioned directory tree — you may consider certain sub-trees to be projects, but Subversion doesn't treat them differently from any other sub-tree. Thus, the interpretation of what constitutes a project in the repository is left entirely up to the users. (This is similar to how <a href="https://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html" >branches</a> and <a href="https://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html" >tags</a> are conventions built on top of copies, instead of being basic concepts built into Subversion itself.)</p> <p>Each time you commit a change, the repository stores a new revision of that overall repository tree, and labels the new tree with a new revision number. Of course, most of the tree is the same as the revision before, except for the parts you changed.</p> <p>The new revision number is a sequential label that applies to the entire new tree, not just to the files and directories you touched in that revision. However, colloquially, a revision number is used to refer to the change committed in that revision; for example, "the change in r588" ("r588" is shorthand for "revision 588") really means "the difference between repository trees 587 and 588", or put another way, "the change made to tree 587 to produce tree 588".</p> <p>Thus, the advancing revision number marks the progress of the repository as a whole; you generally can't gauge the progress of a particular project within the repository by watching the revision number. Also, the revision number should not be used as the publicly-visible release number of a particular project in the repository. For that, you should devise some other mechanism of distinguishing releases, such as using <a href="https://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html" >tags</a>.</p> </div> <div class="h3" id="changesets"> <h3>Does Subversion have Changesets? <a class="sectionlink" href="#changesets" title="Link to this section">¶</a> </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"> <h3>When's the next release? <a class="sectionlink" href="#release" title="Link to this section">¶</a> </h3> <p>See our <a href="/roadmap.html">Roadmap page</a>.</p> </div> <div class="h3" id="symlinks"> <h3>Does Subversion support symlinks? <a class="sectionlink" href="#symlinks" title="Link to this section">¶</a> </h3> <p>Subversion 1.1 (and later) has the ability to put a (unix) 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.</p> <p>On Windows, the svn client currently has no support for translating a versioned symlink into one of the Windows symlink variants (junction points etc.). The checked out object appears as a normal file. One of the issues that make this difficult to support in general is that by default only Administrators can create symlinks on Windows. For more information, see <a href="https://issues.apache.org/jira/browse/SVN-3570">issue SVN-3570</a>. </p> </div> <div class="h3" id="logo"> <h3>I need a high resolution version of the Subversion logo, where can I get it? <a class="sectionlink" href="#logo" title="Link to this section">¶</a> </h3> <p>The following versions of the Subversion logo are available:</p> <ul> <li>An <a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/logo/subversion_logo.svg" ><acronym title="Scalable Vector Graphics">SVG</acronym> version</a></li> <li>An <a href="https://svn.apache.org/repos/asf/subversion/site/publish/logo/subversion_logo.eps" ><acronym title="Encapulated PostScript">EPS</acronym> version</a></li> <li>An <a href="https://svn.apache.org/repos/asf/subversion/site/publish/logo/subversion_logo.ai">Adobe Illustrator document</a></li> </ul> <p>Some additional artwork is available in Subversion's source tree under <a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/logo/">notes/logo</a> and in <a href="/logo/">this Web site</a>.</p> </div> <div class="h3" id="more-information"> <h3>I have other questions. Where can I get more information? <a class="sectionlink" href="#more-information" title="Link to this section">¶</a> </h3> <p>If you don't find an answer after browsing this FAQ, there are several other resources available:</p> <ul> <li><a href="https://svnbook.red-bean.com/">The Subversion <b>Book</b></a> (free to read online)</li> <li>The Subversion Users <b>mailing list</b> <a href="mailto:users@subversion.apache.org">users@subversion.apache.org</a> (<a href="mailing-lists.html">full details</a> including public archives, subscribe, unsubscribe; <a href="#moderation">moderated</a>)</li> </ul> </div> <div class="h3" id="moderation"> <h3>Why isn't my post showing up on the mailing list? <a class="sectionlink" href="#moderation" title="Link to this section">¶</a> </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 class="h3" id="irc"> <h3>Where are the IRC channels? <a class="sectionlink" href="#irc" title="Link to this section">¶</a> </h3> <p>Previously there were official IRC channels #svn and #svn-dev on freenode.net (until May 2021) and on irc.libera.chat (from May 2021). Due to the low number of participants, we no longer recommend using these channels for support and/or development questions.</p> <p>Archives are available <a href="https://colabti.org/irclogger/irclogger_logs/svn">here</a>. </p> </div> <div class="h3" id="dst-2007"> <h3>How is Subversion affected by changes in Daylight Savings Time (DST)? <a class="sectionlink" href="#dst-2007" title="Link to this section">¶</a> </h3> <p>Changes to DST do not require any special changes or fixes to the Subversion code. Subversion primarily uses dates/times to record when changes have been committed to the repository. This code runs on the server and gets the current date/time from the operating system and converts it to UTC using routines provided by the operating system. The Subversion client receives these dates from the server and converts them to the local time zone for display using routines provided by the client operating system. As such, you should only need to install the patches provided for your operating system and really you should only need to make sure the time on the server is properly adjusted for DST.</p> </div> <div class="h3" id="shattered-sha1"> <a name="shatterd-sha1"></a> <h3>How is Subversion affected by SHA-1 hash collisions? <a class="sectionlink" href="#shattered-sha1" title="Link to this section">¶</a> </h3> <p>Publication of the first known SHA-1 collision by <a href="https://shattered.io/"> Google and CWI</a> unveiled a couple of related issues in Subversion's use of SHA-1. Subversion's core does not rely on SHA-1 for content indexing, but it was being used for such purposes in the following supplementary features: </p> <ul> <li>repository data deduplication feature (the "rep cache"), and</li> <li>content deduplication feature in the working copy.</li> </ul> <p>Speaking of the repository data deduplication feature, this can result in inability to access files with colliding SHA-1 values or cause data loss for such files. To prevent different content with identical SHA-1 from being stored in a repository, upgrade to 1.9.6 or 1.8.18 which, by default, prevent storing data with such collisions. See our <a href="/security/sha1-advisory.txt">SHA-1 advisory</a> for details. </p> <p> Until the upgrade to these new releases is available, Unix-based servers can use the pre-commit hook found <a href="https://svn.apache.org/repos/asf/subversion/trunk/tools/hook-scripts/reject-known-sha1-collisions.sh"> here</a>. As an aside, we welcome Windows developers to submit a pre-commit script for the Windows platform. More information on submission can be found <a href="https://subversion.apache.org/docs/community-guide/general.html#patches"> here</a>. </p> <p> The working copy uses SHA-1 for deduplication of the stored content, and for performance reasons a client will avoid fetching content with the same SHA-1 checksum. The workaround for this issue is to prevent storage of the colliding objects in the first place, via upgrade to 1.9.6 or installation of the aforementioned pre-commit script. </p> <p> Storing content with SHA-1 collisions is not a supported use case. If you have content with colliding SHA-1 hash values, we suggest you transform it via gzip before committing it to avoid the collision altogether. Moreover, an upgrade to 1.9.6 to prevent future insertion of duplicates is highly recommended. </p> </div>  </div> <div class="h2" id="how-to"> <h2>How-to: <a class="sectionlink" href="#how-to" title="Link to this section">¶</a> </h2> <p/> <div class="h3" id="co-svn"> <h3>How do I check out the Subversion code? <a class="sectionlink" href="#co-svn" title="Link to this section">¶</a> </h3> <p>Use the Subversion client:</p> <pre> $ svn co https://svn.apache.org/repos/asf/subversion/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"> <h3>How do I create a repository? How do I import data into it? <a class="sectionlink" href="#repository" title="Link to this section">¶</a> </h3> <p>See <a href="/quick-start">Quick Start</a>. For some more detail, see the <a href="https://svnbook.red-bean.com/nightly/en/svn.intro.quickstart.html"> quick start instructions in The Subversion Book</a>.</p> <p>For even more detail about repository setup and administration, read <a href="https://svnbook.red-bean.com/nightly/en/svn.reposadmin.html"> chapter 5 in The Subversion Book</a>.</p> </div> <div class="h3" id="cvs2svn"> <h3>How do I convert an existing CVS repository into a Subversion repository? <a class="sectionlink" href="#cvs2svn" title="Link to this section">¶</a> </h3> <p>The cvs2svn conversion tool seems to be what most people use. The sources are hosted at <a href="https://github.com/mhagger/cvs2svn" >https://github.com/mhagger/cvs2svn</a>. If you are running a Linux or BSD-based system, your distribution might have a cvs2svn package.</p> <p>If cvs2svn doesn't meet your needs, you might try refinecvs written by Lev Serebryakov at <a href="http://lev.serebryakov.spb.ru/refinecvs/" >http://lev.serebryakov.spb.ru/refinecvs/</a>.</p> </div> <div class="h3" id="proxy"> <h3>What if I'm behind a proxy? <a class="sectionlink" href="#proxy" title="Link to this section">¶</a> </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. In many other cases proxies don't filter https as strict as they filter http. The <tt>svn.apache.org</tt> repository server listens on https as well as http. Try:</p> <pre> svn checkout https://svn.apache.org/repos/asf/subversion/trunk subversion </pre> <p>and maybe the proxy will let you through.</p> <p>Of course, your svn client will have to have been built with ssl support. You can check to see whether the 'https' scheme is supported by running <tt>svn --version</tt>.</p> </div> <div class="h3" id="reverseproxy"> <h3>I need to put Subversion behind a reverse proxy <a class="sectionlink" href="#reverseproxy" title="Link to this section">¶</a> </h3> <p>A reverse proxy can be used if the Subversion server is not directly connected to the internet. It will forward HTTP/HTTPS traffic from a public facing server to the Subversion server, potentially removing HTTPS encryption. It can also be useful if several different HTTP servers must be served on the same port.</p> <p>Subversion uses a subset of the WebDAV/DeltaV protocol; see <a href="#http-methods">this FAQ item</a> for the details. As far as the proxy server is concerned, Subversion uses plain WebDAV protocol. For the <tt>svn copy</tt> and <tt>svn move</tt> commands, an extra HTTP_DESTINATION header is used; this must be rewritten separately.</p> <p>Detailed instructions are provided for a few different proxy servers. It should be fairly easy to copy the ideas from these examples.</p> <h4>Detailed instructions for Apache HTTPD</h4> <p>The information below is based on an article written by Konrad Rosenbaum, originally found on <a href="http://silmor.de/proxysvn.php" >http://silmor.de/proxysvn.php</a>. Copied with permission.</p> <p>The proxy side of Apache requires mod_proxy to work. In many Linux distributions there are ready-made configuration files that can be activated, otherwise insert this configuration in httpd.conf:</p> <pre> #load the module LoadModule proxy_module modules/mod_proxy.so #per default disallow all requests (for security) ProxyRequests Off <Proxy *> Order deny,allow Deny from all </Proxy> ProxyVia On </pre> <p>In the VirtualHost directive for the proxying virtual host, configure requests for your subversion directory (we'll assume it is called svn) to be relayed to the real subversion server:</p> <pre> ProxyPass /svn/ http://realsvnserver/svn/ <Location /svn/> ProxyPassReverse /svn/ http://realsvnserver/svn/ <Limit OPTIONS PROPFIND GET REPORT MKACTIVITY PROPPATCH PUT CHECKOUT MKCOL MOVE COPY DELETE LOCK UNLOCK MERGE> Order Deny,Allow Allow from all Satisfy Any </Limit> RewriteCond %{HTTP:Destination} .+/(svn/.*$) RewriteRule ^/svn/.* - [E=MyDestination:http://realsvnserver/%1,PT] RequestHeader set Destination %{MyDestination}e env=MyDestination </Location> </pre> <p>The ProxyPass directive tells Apache to redirect requests below /svn to the subversion-Apache (http://realsvnserver/svn). The ProxyPassReverse directive tells it to alter the request headers (Location, Content-Location, and URI) to match the target server — depending on your version of Apache and its configuration you may need to leave out either /svn/ or http://realsvnserver/svn/. If possible the same path should be used on both servers (otherwise DAV might make trouble). The Limit directive tells Apache to let all DAV requests from all clients (Allow) through and let the real subversion server handle authentication (Satisfy). The Rewrite rules update the HTTP_DESTINATION header to the correct server/protocol.</p> <h4>Detailed instructions for Microsoft IIS</h4> <p>First download and install the URL Rewrite module from <a href="https://www.iis.net/downloads/microsoft/url-rewrite">iis.net</a>. The example below has been tested with IIS 10 and URL Rewrite 2.1.<br/> Next configure URL Rewrite to allow the HTTP_DESTINATION server variable: In IIS Manager under URL Rewrite, in the right hand pane click View Server Variables and add HTTP_DESTINATION.<br/> Finally create a few rewrite rules: <ul> <li>"ToHttps", if you would like to ensure all Subversion traffic is encrypted, this sends an HTTP redirect to the client if the request is sent unencrypted.</li> <li>"ProxyWithDestination", capturing all requests with the HTTP_DESTINATION server variable (ie. all <tt>svn copy</tt> and <tt>svn move</tt> requests). The HTTP_DESTINATION header is rewritten and the traffic is forwarded to the Subversion server. </li> <li>"ProxyRest", forwarding all other traffic to the Subversion server.</li> </ul> The example below can be copied into web.config. It assumes the Subversion server is running on port 81 on the same computer as IIS.</p> <pre> <system.webServer> <rewrite> <rules> <clear /> <rule name="ToHttps" stopProcessing="true"> <match url="(.*)" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> <add input="{HTTPS}" pattern="^OFF$" /> </conditions> <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}"/> </rule> <rule name="ProxyWithDestination" enabled="true" patternSyntax="ECMAScript" stopProcessing="true"> <match url="(.*)" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false"> <add input="{HTTP_DESTINATION}" pattern="https://(.*)"/> </conditions> <serverVariables> <set name="HTTP_DESTINATION" value="http://{C:1}" /> </serverVariables> <action type="Rewrite" url="http://127.0.0.1:81/{R:0}" logRewrittenUrl="true" /> </rule> <rule name="ProxyRest" patternSyntax="ECMAScript" stopProcessing="true"> <match url="(.*)" negate="false" /> <conditions logicalGrouping="MatchAll" trackAllCaptures="false" /> <action type="Rewrite" url="http://127.0.0.1:81/{R:0}" logRewrittenUrl="true" /> </rule> </rules> </rewrite> <security> <requestFiltering allowDoubleEscaping="true" /> </security> </system.webServer> </pre> </div> <div class="h3" id="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? <a class="sectionlink" href="#paranoid" title="Link to this section">¶</a> </h3> <p>A simple option is to use the <b>svnserve</b> server instead of Apache. See <a href="https://svnbook.red-bean.com/nightly/en/svn.serverconfig.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>  <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="https://web.archive.org/web/20150618070908/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> (on archive.org)</li> <li><a href="https://engineering.purdue.edu/ECN/Support/KB/Docs/SSHIntroductionToSSH" >https://engineering.purdue.edu/ECN/Support/KB/Docs/SSHIntroductionToSSH</a></li> </ul> </div> <div class="h3" id="multi-proj"> <h3>How do I manage several different projects under Subversion? <a class="sectionlink" href="#multi-proj" title="Link to this section">¶</a> </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 <sussman@collab.net>):</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"> <h3>How do I merge two completely separate repositories? <a class="sectionlink" href="#multi-merge" title="Link to this section">¶</a> </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 <peter@pdavis.cx> 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> <p>There are also some helpful tools floating around on the internet, to select and reorder revisions when merging several repositories. For instance the <a href="https://www.cri.ensmp.fr/people/coelho/svn-merge-repos.html">svn-merge-repos.pl</a> perl script for basic operations and the <a href="https://svn.borg.ch/svndumptool/">SvnDumpTool</a> python classes for advanced reorganisations.</p> </div> <div class="h3" id="nfs"> <h3>Should I store my repository / working copy on a NFS server? <a class="sectionlink" href="#nfs" title="Link to this section">¶</a> </h3> <p>If you are using the <b>FSFS repository back end</b> (which has been the default since Subversion 1.2), then storing the repository on a modern NFS server (i.e., one that supports locking) should be fine.</p> <p>If you are using a repository with the <b>Berkeley DB back end</b> (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><b>Working copies</b> 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/ar01s03.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="reposperms"> <h3>How do I set repository permissions correctly? <a class="sectionlink" href="#reposperms" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.serverconfig.multimethod.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="removal"> <h3> How do I completely remove a file from the repository's history? <a class="sectionlink" href="#removal" title="Link to this section">¶</a> </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="https://issues.apache.org/jira/browse/SVN-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="https://svnbook.red-bean.com/nightly/en/svn.reposadmin.html" >chapter 5</a> of the Subversion book for details about this.</p> <p>An alternative approach is to <a href="https://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.replication" >replicate the repository with <b>svnsync</b></a> after configuring <a href="https://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html" >path-based authorization</a> rules that deny read access to any paths that need to be filtered from history. Unlike <b>svndumpfilter</b>, <b>svnsync</b> will automatically translate copy operations with an unreadable source path into normal additions, which is useful if history involving copy operations needs to be filtered.</p> </div> <div class="h3" id="change-log-msg"> <h3> How do I change the log message for a revision after it's been committed? <a class="sectionlink" href="#change-log-msg" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html">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="https://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks" >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"> <h3>How do I submit a patch for Subversion? <a class="sectionlink" href="#patch" title="Link to this section">¶</a> </h3> <p>FIRST, read the <a href="/docs/community-guide/">Subversion Community Guide</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 https://svn.apache.org/repos/asf/subversion/site subversion-site $ cd subversion-site/publish [ make changes to faq.html ] $ svn diff faq.html > /tmp/foo $ Mail -s "[PATCH] FAQ updates" < /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="/docs/community-guide/">Subversion Community Guide</a>, but you already know that, since you read and completely understood it <em>before</em> actually hacking the code, right? :)</p> <p>Looking for something to do? Take a look at our <a href="/ideas.html">ideas page</a>.</p> </div> <div class="h3" id="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)? <a class="sectionlink" href="#in-place-import" title="Link to this section">¶</a> </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 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 add</tt> commands to select files and subtrees to add to the repository.</p> <p>If the <em>entire</em> contents of the directory shall be imported, rather than a subset of contents, this shorter sequence of commands can be used to perform the import and then transform the directory into a Subversion working copy:</p> <pre> # cd /etc # svn import file:///root/svn-repository/etc # svn checkout --force file:///root/svn-repository/etc . </pre> <p>There is an issue filed for enhancing <tt>svn import</tt> to be able to convert the imported tree to a working copy automatically; see <a href="https://issues.apache.org/jira/browse/SVN-1328" >issue 1328</a>.</p> </div> <div class="h3" id="dumpload"> <h3>What is this "dump/load cycle" people sometimes talk about when upgrading a Subversion server? <a class="sectionlink" href="#dumpload" title="Link to this section">¶</a> </h3> <p>Subversion's repository database schema has changed occasionally during development. To take advantage of new features, you may have to dump and load the repository to recreate the back-end database. However, most upgrades of Subversion do <i>not</i> involve a dump and load. When one is required, the release notes 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> <p>An alternative to dump/load is using <a href="https://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.replication" >svnsync</a> to replicate the repository into a new one. This is a bit slower, but is more flexible, and has some extra normalization-features which are not (yet) available with dump/load (svnsync normalizes properties to LF line-endings on the fly and has a --source-prop-encoding option to convert them to UTF-8, which is required in newer repository formats --- see below for how to handle this with dump/load).</p> <p><b>Note: </b>Both dump/load and svnsync <b>only cover the repository database, not the repository hook scripts, configuration files and locks</b>. These need to be copied over manually from source to target (see below in the "complex procedure"). If you need to copy the complete repository, without rebuilding the back-end database, <a href="https://svnbook.red-bean.com/en/1.8/svn.reposadmin.maint.html#svn.reposadmin.maint.backup" >svnadmin hotcopy</a> may be a better option.</p> <p>For small repositories that can afford some downtime, this is a simple dump/load procedure to upgrade from Subversion version X to Y ( see below for a more complex procedure with minimal downtime for larger repositories):</p> <ol> <li>Shut down svnserve, Apache, and anything else that might be accessing the repository. </li> <li> <b> <tt>svnadmin dump /path/to/repository > dumpfile.txt</tt> </b>, using version X of svnadmin. </li> <li> <b> <tt>mv /path/to/repository /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 create /path/to/repository</tt></b>, using version Y of svnadmin. </li> <li> <b> <tt>svnadmin load /path/to/repository < 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>For larger repositories, where you want to minimize the maintenance window, a slightly more complex procedure can be used. The trick is to dump+load to a new location, while the old repository is still accessible (for checkouts and commits). After this is done (can take hours, or even days, weeks) you note the last revision which was loaded (or check the revision number with 'svnlook youngest newrepos'), and start another dump+load where you dump with '--incremental -rNEXTREV:HEAD' (where NEXTREV is the next revision that needs to be dumped). You can iterate over this as long as you keep the old repository open ... At the end you make the original repository inaccessible for a couple of minutes, while you enable the new one (Caveat: if you move your new repos in the same disk location as the old one, and you use Apache httpd to serve it, make sure you restart httpd to reset its caches).</p> <p>Tip: for a large repo I strongly suggest building the new repository (the target of your 'svnadmin load') on very fast storage, even ramdisk if possible, and running 'svnadmin pack' while on fast storage (and copy it over to the final disk afterwards). It's the 'svnadmin load' part that is very time-consuming right now (this will probably be much improved in svn 1.10, with the --no-flush-to-disk option for 'svnadmin load').</p> <p>Your commands will look like the following:</p> <ol> <li><b> <tt>svnadmin create NEWREPOS</tt> </b> <br/>(maybe create it on a ramdisk) </li> <li> If you have custom hook scripts in <b><tt>OLDREPOS/hooks</tt></b> (all files not ending in .tmpl, as those are the default templates), review them, and copy them over to <b><tt>NEWREPOS/hooks</tt></b>. Check the new templates corresponding to your custom hook scripts to see if there are new options and comments (you might want to copy the newer comments from the template into your custom hook script, to keep it up to date). Make sure the files are not changed anymore until the end of the entire procedure (or carry over additional changes at the end). </li> <li> Review and copy config files from <b><tt>OLDREPOS/conf</tt></b> to <b><tt>NEWREPOS/conf</tt></b> (here too, take a look at the new "default config files" to see if there are new interesting options or comments). Make sure the files are not changed anymore until the end of the entire procedure (or carry over additional changes at the end). </li> <li><b> <tt>svnadmin dump -M 1024 OLDREPOS | svnadmin load -M 1024 NEWREPOS</tt> </b> <br/>(initial dump+load; you might want to pass -q to dump and/or load to make it more quiet) <br/>(the -M 1024 gives the process 1024 MB extra ram for caching) </li> <li><b> <tt>svnlook youngest NEWREPOS</tt> </b> <br/>(last revision that was loaded -> NEXTREV is this last revision + 1) </li> <li><b> <tt>svnadmin dump --incremental -rNEXTREV:HEAD -M 1024 | svnadmin load -M 1024 NEWRPOS</tt> </b> </li> <li> Make OLDREPOS read-only or completely unavailable <b><-- start of maintenance window</b> </li> <li> Possibly repeat the incremental dump+load of steps 5 and 6 (if new commits happened after you started 6). </li> <li> Copy locks from <b><tt>OLDREPOS/db/locks</tt></b> to <b><tt>NEWREPOS/db/locks</tt></b>. Something like 'cp -rp SOURCE TARGET' works fine for this. <b>Note: this step may take a couple of minutes during your maintenance window, depending on the size of the directory tree and the speed of the disk(s). If you want to make sure, test this in advance (but make sure the source repository is readonly when you do the final copy / sync, otherwise the locks might be changed after your copy).</b> </li> <li> Put NEWREPOS online <b><-- end of maintenance window</b> </li> </ol> <p>Some things to watch out for:</p> <ul> <li>Watch out for <a href="#change-log-msg">changes to log messages</a> (or other revision properties) after you start the initial dump+load and before you lock down the old repository. Those won't be transferred with the incremental dump+load(s). So either make sure the pre-revprop-change hook is "closed" while you're running the initial dump+load, or keep a log of all changed revision properties (for instance write them to a log file from your post-revprop-change hook) and transfer them to the new repository afterwards (for instance using 'svnlook log' and 'svnadmin setlog'). </li> <li>You might run into: <pre> svnadmin: E125005: Invalid property value found in dumpstream; consider repairing the source or using --bypass-prop-validation while loading. svnadmin: E125005: Cannot accept non-LF line endings in '<b>svn:log</b>' property </pre> This means the svn:log message of the revision has non-LF line endings (these were accepted by older servers, but no longer as of Subversion 1.6). You can ignore this minor corruption by adding --bypass-prop-validation to your 'svnadmin load' command (you can always <a href="#fix-nonLF-log">repair</a> this later in the new repository). Or you can try to <a href="#fix-nonLF-log">repair</a> this in the source repository before executing the dump+load (since svn:log is a <i>revision property</i> it can easily be fixed without "rewriting history"). </li> <li>You might run into: <pre> svnadmin: E125005: Invalid property value found in dumpstream; consider repairing the source or using --bypass-prop-validation while loading. svnadmin: E125005: Cannot accept non-LF line endings in '<b>svn:ignore</b>' property </pre> This is more difficult to repair, because 'svn:ignore' is not a revision property (unlike svn:log, which can be manipulated with svnadmin setrevprop), but a <i>versioned property</i> (so it's part of history). Again, you can ignore this with --bypass-prop-validation. But since this is a corruption "in history", this can only be repaired with a dump+load, so this might be a good time to try and fix this (or you'll run into this again in the future). To repair it you can use a tool like <a href="https://github.com/jwiegley/svndumptool">svndumptool</a>. But it only works on dump <i>files</i>, not as part of a pipe. So a possible way to go about it is: dump that single (corrupt) revision to a file, repair it ('svndumptool.py eolfix-prop svn:ignore svn.dump svn.dump.repaired'), load that single dumpfile, and then continue with a new "piped" command (like step (6) above). </li> </ul> <p> See <a href="https://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate" >this section of the Subversion book</a> for more details on dumping and loading.</p> </div> <div class="h3" id="fix-nonLF-log"> <h3>What can I do about <tt>"svnadmin: E125005: Cannot accept non-LF line endings in 'svn:log' property"</tt> while running 'svnadmin load'? <a class="sectionlink" href="#fix-nonLF-log" title="Link to this section">¶</a> </h3> <p>This error means the svn:log message of the revision in your dumpfile / dumpstream has non-LF line endings (these were accepted by older servers, but no longer as of Subversion 1.6). You can ignore this minor corruption while loading into your new repository by adding --bypass-prop-validation to your 'svnadmin load' command (you can always repair this later in the new repository). Or you can try to repair this in the source repository before executing the dump+load (since svn:log is a <i>revision property</i> it can easily be fixed without "rewriting history"). Also note that <tt>svnsync</tt> normalizes this on the fly, so it might be an easier alternative than dump+load.</p> <p>There is no standard procedure for normalizing the line endings in the svn:log property, but using the administrative commands 'svnlook propget', 'svnlook log' and 'svnadmin setlog' can get you there:</p> <ul> <li><tt><b>svnlook propget -r$REV --revprop $REPOS svn:log</b></tt> gets the raw svn:log revision property (no normalization, no extra newline at the end). You can use that to validate it and search for 'non-LF line endings'. </li> <li><tt><b>svnlook log -r$REV $REPOS</b></tt> gets a normalized version of it (LF-eols, normalized to UTF8 (if you have the correct "source encoding" set as your locale), and an extra newline at the end). If you strip of the final newline, this gives you a nice normalized version of the log message to feed to ... </li> <li><tt><b>svnadmin setlog -r$REV $REPOS --bypass-hooks</b></tt> (or without the --bypass-hooks option if you want the hooks to be run) will set the value it's reading from stdin as the new log message. </li> </ul> <p>You can stitch them together into a script to handle all revisions in a repository, like in these bash oneliners:</p> <pre> Find the "broken" revisions and echo the revision numbers: bash$ YOUNGEST=`svnlook youngest $REPOS`; for (( i=1; i<=$YOUNGEST; i++ )); \ do svnlook propget -r $i --revprop $REPOS svn:log | xxd -ps -c1 | fgrep '0d' > /dev/null \ && echo "$i" ; done; echo "Verified until revision $YOUNGEST" </pre> <p></p> <pre> Find and immediately fix the "broken" revisions with 'svnadmin setlog': bash$ YOUNGEST=`svnlook youngest $REPOS`; for (( i=1; i<=$YOUNGEST; i++ )); \ do svnlook propget -r $i --revprop $REPOS svn:log | xxd -ps -c1 | fgrep '0d' > /dev/null \ && echo "Fixing r$i" && svnadmin setlog $REPOS --bypass-hooks -r$i \ <( svnlook log -r$i $REPOS | sed '$d' ); done; echo "Verified until revision $YOUNGEST" (the "sed '$d'" strips off the extra newline that's added by "svnlook log") </pre> </div> <div class="h3" id="sspi"> <h3>How do I allow clients to authenticate against a Windows domain controller using SSPI authentication? <a class="sectionlink" href="#sspi" title="Link to this section">¶</a> </h3> <p class="todo">This FAQ entry has not been updated since 2003 and is known to contain information no longer accurate or relevant.</p> <p><a href="https://tortoisesvn.net/">TortoiseSVN</a> has an excellent document that describes setting up a Subversion server on Windows. Go to <a href="https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup.html#tsvn-serversetup-apache-5" >https://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 support 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"> <h3>I don't like the ".svn" directory name, and prefer "SVN" or something else. How do I change it? <a class="sectionlink" href="#adm-dir" title="Link to this section">¶</a> </h3> <p>We recommend that you live with ".svn" if you possibly can. However, if you are using Visual Studio 2002 or 2003 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"> <h3>How do I change the case of a filename? <a class="sectionlink" href="#case-change" title="Link to this section">¶</a> </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 mv file.java File.java </pre> <p>From Subversion 1.7 onwards, this also works on Windows, even though it's using a case-insensitive filesystem.</p> <p>If you are using Subversion 1.6 or older on Windows, or if you're using a case-insensitive filesystem with an operating system other than Windows, this technique won't work. In this case, 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>case-insensitive.py</tt>. That file lives in the Subversion source tarball, in the directory <tt>contrib/hook-scripts</tt> or can be downloded from the <a href="https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/case-insensitive.py" >repository</a>.</p> </div> <div class="h3" id="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? <a class="sectionlink" href="#merge-using-tags" title="Link to this section">¶</a> </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" >>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"> <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. <a class="sectionlink" href="#version-value-in-source" title="Link to this section">¶</a> </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 make</tt>, add <a href="https://svn.haxx.se/dev/archive-2006-02/1156.shtml" >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 = "' \ > svn_version.c svnversion -n . >> svn_version.c echo '"; return SVN_Version; }' >> 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='https://tortoisesvn.net/downloads.html'>TortoiseSVN download page</a>; it replaces all <tt>$WCREV$</tt> tags in a given file with the current working copy revision. </p> <p> Another alternative is creating a wrapper for 'svn commit', which does some automatic replacement in files before commit (be careful not to mess things up though -- silent manipulation of files right before commit can be scary for a user). That way you can inject any metadata you want (and it will be committed with the regular content of the file into the repository). </p> </div> <div class="h3" id="log-in-source"> <h3>Does Subversion have a keyword which behaves like $Log$ in CVS? <a class="sectionlink" href="#log-in-source" title="Link to this section">¶</a> </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"> <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? <a class="sectionlink" href="#ignore-commit" title="Link to this section">¶</a> </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"> <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? <a class="sectionlink" href="#ssh-auth-cache" title="Link to this section">¶</a> </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="https://www.google.com/search?hl=en&lr=&ie=UTF-8&q=%22ssh-agent%22" >Google search for "ssh-agent"</a> will quickly get you answers.</p> </div> <div class="h3" id="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>. <a class="sectionlink" href="#ssh-svnserve-location" title="Link to this section">¶</a> </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—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 AAAAB3Nblahblahblahblah</tt></td></tr> <tr><th>after</th></tr> <tr><td><tt> command="/opt/subversion/bin/svnserve -t" ssh-dss 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="https://svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks">This file</a> discusses this topic in more detail.</p> </div> <div class="h3" id="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. <a class="sectionlink" href="#ssh-authorized-keys-trick" title="Link to this section">¶</a> </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"> <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? <a class="sectionlink" href="#auto-props" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.auto" >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="https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/check-mime-type.pl" >https://svn.apache.org/repos/asf/subversion/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="https://issues.apache.org/jira/browse/SVN-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"> <h3>How do I deal with spaces in the editor path?  Also, how can I define command line options for the editor? <a class="sectionlink" href="#svn-editor" title="Link to this section">¶</a> </h3> <p>The Subversion command line client will invoke the editor defined in the environment variable SVN_EDITOR.  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 Files\Posix 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.  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 use on the command line.  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.  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="website-auto-update"> <h3>I'm managing a website in my repository. How can I make the live site automatically update after every commit? <a class="sectionlink" href="#website-auto-update" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html#svn.reposadmin.create.hooks" >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 <stddef.h> #include <stdlib.h> #include <unistd.h> 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. <DirectoryMatch "^/.*/\.svn/"> Order deny,allow Deny from all </DirectoryMatch> </pre> <p>Finally, if the working copy to be updated isn't on the same machine as the Subversion server, <a href="https://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svnpubsub">svnpubsub</a> can be used on the Subversion server to advertise the commit to a listening <a href="https://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svnpubsub/svnwcsub.py">svnwcsub</a> client on the Web server.</p> </div> <div class="h3" id="single-file-checkout"> <h3>How do I check out a single file? <a class="sectionlink" href="#single-file-checkout" title="Link to this section">¶</a> </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"> <h3>How do I detect adds, deletes, copies and renames in a working copy after they've already happened? <a class="sectionlink" href="#wc-change-detection" title="Link to this section">¶</a> </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"> <h3>How do I run svnserve as a service on Windows? <a class="sectionlink" href="#svnserve-win-service" title="Link to this section">¶</a> </h3> <p>For versions 1.4.0 and later, you can find instructions <a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/windows-service.txt">here</a>.</p> </div> <div class="h3" id="bdb-fsfs-convert"> <h3>How do I convert my repository from using BDB to FSFS or from FSFS to BDB? <a class="sectionlink" href="#bdb-fsfs-convert" title="Link to this section">¶</a> </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"> <h3>How does Subversion handle binary files? <a class="sectionlink" href="#binary-files" title="Link to this section">¶</a> </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.</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="https://svnbook.red-bean.com/nightly/en/svn.advanced.props.html#svn.advanced.props.auto" >auto-props feature</a> or by setting the property manually with <tt>svn propset</tt>.)</p> <p>Subversion 1.7 and later can optionally be compiled with support for <a href="https://www.darwinsys.com/file/">libmagic</a> to detect MIME types of binary files which are added to version control. This feature is used only for binary files for which no MIME type is found via auto-props or the mime-types-file configuration option. If libmagic identifies a file as a text file, Subversion will treat the file as a text file by default.</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 diff' command.</p> </div> <div class="h3" id="terse-diff"> <h3>How can I make <tt>svn diff</tt> show me just the names of the changed files, not their contents? <a class="sectionlink" href="#terse-diff" title="Link to this section">¶</a> </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"> <h3>How can I use wildcards or globbing to move many files at once? <a class="sectionlink" href="#sorry-no-globbing" title="Link to this section">¶</a> </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> Subversion doesn't expand wildcards like "*" in URL arguments. (Technically speaking, Subversion does not expand wildcards in local paths either, but on most operating systems the shell expands wildcards in local paths in the command line before passing the resulting list to Subversion.) </p> <p> You have to generate the list of source URLs yourself. You could do it like this (in Bash): </p> <pre> s=svn://server/trunk/stuff items=$(svn ls "$s") urls=$(for item in $items; do echo $s/$item; done) svn mv $urls svn://server/trunk/some-other-dir -m "Moved all at once" </pre> <p> In Subversion v1.4 and earlier, Subversion did not allow you to "cp" and "mv" multiple paths or URLs in one command. You have to issue multiple commands. 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" (previously "mucc"), whose source is distributed with Subversion, that enables you to combine multiple commands into one commit. See <a href="tools_contrib.html#svnmucc_c">the Tools and Contrib page</a>. </p> </div> <div class="h3" id="vendor-branch"> <h3>How can I maintain a modified version (a "vendor branch") of third-party software using Subversion? <a class="sectionlink" href="#vendor-branch" title="Link to this section">¶</a> </h3> <p>People frequently want to use Subversion to track their local changes to third-party code, even across upgrades from the third-party — 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="https://svnbook.red-bean.com/en/1.7/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="https://github.com/francois/piston">Piston</a> to manage your copy of the vendor's code.</p> </div> <div class="h3" id="undo"> <h3>How do I make the contents of a previous revision become HEAD again? <a class="sectionlink" href="#undo" title="Link to this section">¶</a> </h3> <p>Use 'svn merge' or 'svn copy', as <a href="https://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo" >described in the Subversion book</a>.</p> </div> </div> <div class="h2" id="troubleshooting"> <h2>Troubleshooting: <a class="sectionlink" href="#troubleshooting" title="Link to this section">¶</a> </h2> <p/> <div class="h3" id="wedged-wc"> <h3>Every time I try to run a svn command, it says my working copy is locked. Is my working copy corrupt? <a class="sectionlink" href="#wedged-wc" title="Link to this section">¶</a> </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"> <h3>I'm trying to commit, but Subversion says my working copy is out of date? <a class="sectionlink" href="#wc-out-of-date" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs.limits" >Mixed revisions have limitations</a> in the <a href="https://svnbook.red-bean.com/">Version Control with Subversion</a> book 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 — 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"> <h3>I've contributed a patch to a project and the patch added a new file. Now <tt>svn update</tt> does not work. <a class="sectionlink" href="#obstructed-add" title="Link to this section">¶</a> </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 received 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"> <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? <a class="sectionlink" href="#unrecognized-url-error" title="Link to this section">¶</a> </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_neon or ra_serf which allow 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_neon or ra_serf.</p> <p>The error you are seeing means that the dynamic linker/loader can't find the plugins to load. For `http://' access, this normally means that you have not linked Subversion to neon or serf when compiling it (check the configure script output and the config.log file for information about this). It also 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"> <h3>I'm getting errors finding or opening a repository, but I know my repository URL is correct. What's wrong? <a class="sectionlink" href="#db-recover" title="Link to this section">¶</a> </h3> <p>See <a href="#bdb-recovery">this faq.</a></p> </div> <div class="h3" id="configure-sed-error"> <h3>When I run `<tt>configure</tt>', I get errors about <tt>subs-1.sed line 38: Unterminated `s' command</tt>. What's wrong? <a class="sectionlink" href="#configure-sed-error" title="Link to this section">¶</a> </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"> <h3>I'm having trouble building Subversion under Windows with MSVC++ 6.0. What should I do? <a class="sectionlink" href="#windows-msvc-build" title="Link to this section">¶</a> </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"> <h3>How can I specify a Windows drive letter in a <tt>file:</tt> URL? <a class="sectionlink" href="#windows-drive-letter" title="Link to this section">¶</a> </h3> <p>Like this:</p> <pre> svn import file:///d:/some/path/to/repos/on/d/drive </pre> <p>See <a href="https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.advanced.reposurls"> Subversion Repository URLs</a> in the Subversion Book for more details.</p> </div> <div class="h3" id="vs-asp-net"> <h3>Microsoft Visual Studio 2002 and 2003 seem to have a problem with the ".svn" directory name. What should I do? <a class="sectionlink" href="#vs-asp-net" title="Link to this section">¶</a> </h3> <p>Visual Studio can use a web subsystem for ASP.Net, which uses frontpage server extensions 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 — this will tell Windows clients to use "_svn" as a directory name in your working copy. See <a href="/docs/release-notes/1.3.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"> <h3>I'm having trouble doing write operations to a Subversion repository over a network. <a class="sectionlink" href="#write-over-dav" title="Link to this section">¶</a> </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 : <Activity not found> 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="net-trace"> <h3>What is the best method of doing a network trace of the conversation between a Subversion client and server? <a class="sectionlink" href="#net-trace" title="Link to this section">¶</a> </h3> <p>Please see <a href="/docs/community-guide/debugging.html#net-trace" >/docs/community-guide/debugging.html#net-trace</a>.</p> </div> <div class="h3" id="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. <a class="sectionlink" href="#revert" title="Link to this section">¶</a> </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—even if that target is just '.'—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="no-author"> <h3>Why does SVN log say "(no author)" for files committed or imported via Apache (ra_dav)? <a class="sectionlink" href="#no-author" title="Link to this section">¶</a> </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:  (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003) </pre></blockquote> <p>See <a href="https://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html" >the Subversion book</a> to learn about configuring access restrictions in Apache.</p> </div> <div class="h3" id="windows-access-denied"> <h3>I'm getting occasional "Access Denied" errors on Windows. They seem to happen at random. Why? <a class="sectionlink" href="#windows-access-denied" title="Link to this section">¶</a> </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= "https://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"> <h3>On FreeBSD, certain operations (especially svnadmin create) sometimes hang. Why? <a class="sectionlink" href="#freebsd-hang" title="Link to this section">¶</a> </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> <div class="h3" id="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? <a class="sectionlink" href="#http-301-error" title="Link to this section">¶</a> </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><Location /www/foo></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><Location></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="xlc-compile"> <h3>Compiling with xlc on AIX, I get compilation errors. What's wrong? <a class="sectionlink" href="#xlc-compile" title="Link to this section">¶</a> </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="https://svn.haxx.se/dev/archive-2004-01/0922.shtml" >https://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"> <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. <a class="sectionlink" href="#nonrecursive-checkout" title="Link to this section">¶</a> </h3> <p>See <a href="https://issues.apache.org/jira/browse/SVN-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"> <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> <a class="sectionlink" href="#mod_dav_svn-win32" title="Link to this section">¶</a> </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>intl3_svn.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="https://www.dependencywalker.com/">Dependency Walker</a> on <tt>mod_dav_svn.so</tt> to see if there are any other unresolved dependencies.</p> </div> <div class="h3" id="hook-debugging"> <h3>Why aren't my repository hooks working? <a class="sectionlink" href="#hook-debugging" title="Link to this section">¶</a> </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>Make sure the hook script is named correctly: for example, the post-commit hook should be named <tt>post-commit</tt> (without extension) on Unix, and <tt>post-commit.bat</tt> or <tt>post-commit.exe</tt> on Windows.</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"> <h3>Why does my --diff-cmd complain about '-u'? I tried to override it with --extensions, but it's not working. <a class="sectionlink" href="#diff-cmd" title="Link to this section">¶</a> </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="https://issues.apache.org/jira/browse/SVN-2044">#2044</a>.</p> </div> <div class="h3" id="plaintext-passwords"> <h3>How does Subversion cache credentials (plaintext and encrypted)? <a class="sectionlink" href="#plaintext-passwords" title="Link to this section">¶</a> </h3> <p>To avoid having to type a password for each server operation, Subversion can cache credentials.</p> <p>Passwords may have been cached unencrypted by older versions of Subversion ("grandfathered in") and Subversion always supports reading these. Whether and how Subversion caches new credentials depends on several factors, including the access method, operating system, compile-time options, and settings in the client's run-time config file.</p> <p>To show the credentials in your cache, use <tt>svn auth</tt>. Credentials are never removed automatically but may be removed manually using <tt>svn auth --remove</tt>.</p> <h4>Windows</h4> <p>On Windows, Subversion uses standard Windows APIs to encrypt the data, so only the user can decrypt the cached password. <i>(Since Subversion 1.2.)</i></p> <h4>macOS (formerly Mac OS X)</h4> <p>On macOS, Subversion uses the system Keychain facility to encrypt/store the user's svn password. <i>(Since Subversion 1.4.)</i></p> <h4>UNIX/Linux</h4> <p>On UNIX/Linux, Subversion supports up to four credential caches:</p> <ul> <li>GNOME Keyring</li> <li>KWallet</li> <li>GPG-Agent</li> <li>Plaintext cache in ~/.subversion/auth/svn.simple/</li> </ul> <p>To determine which credential caches your Subversion client supports, run the <tt>svn --version</tt> command and look for "The following authentication credential caches are available" toward the end of its output.</p> <p>GNOME Keyring and KWallet both facilitate storing passwords on disk encrypted. For Subversion to support these programs (since Subversion 1.6), they need to be available at compile-time and at run-time.</p> <p class="todo">TODO: Discuss GPG-Agent.</p> <p>Depending on a compile-time option (--enable-plaintext-password-storage) and runtime configurations (see below) Subversion <i>may</i> fallback to storing passwords in the Plaintext cache.</p> <p>The default value of --enable-plaintext-password-storage was changed from True to False in Subversion 1.12, thus disabling the Plaintext cache unless explicitly enabled.</p> <p>The directory which contains cached Plaintext passwords (usually <tt>~/.subversion/auth/</tt>) has permissions of 700, meaning only the user (and root) can read them.</p> <h4>"Subversion was compiled with support for Plaintext password cache but I want to prevent writing passwords to the Plaintext cache."</h4> <p>The following options are available in your run-time config file (per user ~/.subversion/config and ~/.subversion/servers, systemwide /etc/subversion/config and /etc/subversion/servers):</p> <ul> <li>To allow encrypted stores like GNOME Keyring and KWallet, but not the Plaintext cache, set <tt>store-plaintext-passwords = no</tt>.</li> <li>To allow caching server certs but not passwords (encrypted or not), set <tt>store-passwords = no</tt>.</li> <li>To disable storing any kind of credentials (encrypted or not) set <tt>store-auth-creds = no</tt>.</li> </ul> <h4>"I want to use the Plaintext cache but it wasn't enabled at compile time."</h4> <p>In response to various questions and requests, the Subversion developers have written a Python script that can store a plain-text password to the cache. If you understand the security implications, have ruled out other alternatives, and still want to cache your password in plain-text on disk, you may find the script <a href="https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/store-plaintext-password.py" >in the <tt>tools/client-side/</tt> directory in (as of this writing) our trunk</a>.</p> <h4>Additional Information</h4> <p>More information on password caching is in Chapter 6 of the <a href="https://svnbook.red-bean.com/en/1.7/index.html">Subversion book</a>, under <a href="https://svnbook.red-bean.com/en/1.7/svn.serverconfig.netmodel.html#svn.serverconfig.netmodel.credcache" >"Client Credentials Caching".</a></p> </div> <div class="h3" id="hotcopy-large-repos"> <h3>I can't hotbackup my repository, svnadmin fails on files larger than 2Gb! <a class="sectionlink" href="#hotcopy-large-repos" title="Link to this section">¶</a> </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"> <h3>I cannot see the log entry for the file I just committed. Why? <a class="sectionlink" href="#hidden-log" title="Link to this section">¶</a> </h3> <p>Assume you run '<tt>svn 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 spend some time modifying the file and then commit it successfully. Two things happen:</p> <ul> <li>The repository moves to a new HEAD revision on the server. The number of the new HEAD revision depends on how many other commits were made since your working copy was checked out. For example, the new HEAD revision might be r20.</li> <li>In your working copy, only the file <tt>foo.c</tt> moves to r20. The rest of your working copy remains at r7.</li> </ul> <p>You now have what is known as a <i><a href="https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs.update-commit">mixed revision working copy</a></i>. One file is at r20, but all other files remain at r7 until they too are committed, or until '<tt>svn update</tt>' is run.</p> <pre> $ svn -v status 7 7 nesscg . 20 20 nesscg foo.c $</pre> <p>If you run the '<tt>svn 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 r20.</p> <p>To see the latest logs, do one of the following:</p> <ol> <li>Run '<tt>svn log -rHEAD</tt>'.</li> <li>Run '<tt>svn log URL</tt>', where URL is the repository URL. If the current directory is a working copy you can abbreviate the URL to the repository root as <tt>^/</tt> to save some typing. Note that on Windows the "^" symbol is special and must be quoted. E.g.: <tt>svn log "^/" --limit 10</tt></li> <li>Run '<tt>svn log URL</tt>', where URL is the URL of the subdirectory you want to see the log for, for example: <tt>svn log ^/trunk</tt></li> <li>Ask for just that file's log information, by running '<tt>svn log foo.c</tt>'.</li> <li>Update your working copy so it's all at r20, then run '<tt>svn log</tt>'.</li> </ol> </div> <div class="h3" id="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)? <a class="sectionlink" href="#tiger-apr-0.9.6" title="Link to this section">¶</a> </h3> <p>Note: this assumes the repository is being served by Apache 2.0.x.</p> <p>There is <a href="https://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  —  assuming you have access to the machine that the repository is being served from  —  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"> <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? <a class="sectionlink" href="#debian-libtool" title="Link to this section">¶</a> </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 — I didn't have time to verify the details before writing this FAQ entry. However, see <a href="https://svn.haxx.se/dev/archive-2006-02/1214.shtml" >https://svn.haxx.se/dev/archive-2006-02/1214.shtml</a> and the thread 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="https://www.gnu.org/software/libtool/libtool.html">libtool 1.5.20</a> from source, using the standard "./configure && make && sudo make install" recipe. After that, I did a 'make 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="https://svn.haxx.se/dev/archive-2003-01/1125.shtml" >https://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="svnserve-listen-host"> <h3>I've started svnserve, but it doesn't seem to be listening on port 3690. <a class="sectionlink" href="#svnserve-listen-host" title="Link to this section">¶</a> </h3> <p>Invoke <tt>svnserve</tt> with the <tt>--listen-host=0.0.0.0</tt> option. Svnserve does not properly support IPv4/IPv6 dual-stack operation. See <a href="https://issues.apache.org/jira/browse/SVN-2382" >issue #2382</a>.</p> </div> <div class="h3" id="already-under-version-control"> <h3>I can't add a directory because Subversion says it's "already under version control". <a class="sectionlink" href="#already-under-version-control" title="Link to this section">¶</a> </h3> <p>The directory you're trying to add already contains a <tt>.svn</tt> subdirectory — it is a working copy — but it's from a different repository location than the directory to which you're trying to add it. This probably happened because you used your operating system's "copy" command (instead of <tt>svn copy</tt>) to copy a subdirectory in this working copy, or to copy some other working copy into this 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, if the copy was from the same repository, you should ideally delete or move aside the copy, and use <tt>svn copy</tt> to make a proper copy, which will know its history and save space in the repository.</p> <p>If it was from a different repository, 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"> <h3>Accessing non-public repositories via svnserve is really slow sometimes. <a class="sectionlink" href="#slow-private-svnserve" title="Link to this section">¶</a> </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"> <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>. <a class="sectionlink" href="#ssl-negotiation-error" title="Link to this section">¶</a> </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"> <h3>I get an error that says "This client is too old". <a class="sectionlink" href="#broken-subclipse" title="Link to this section">¶</a> </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—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. As of Subversion 1.5, a helper script is provided to downgrade working copies to formats compatible with earlier releases of Subversion; see <a href="#working-copy-format-change">this faq.</a> </div> <div class="h3" id="switch-problems"> <h3>Why doesn't <tt>svn switch</tt> work in some cases? <a class="sectionlink" href="#switch-problems" title="Link to this section">¶</a> </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="https://issues.apache.org/jira/browse/SVN-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="https://issues.apache.org/jira/browse/SVN-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 '<dir>' 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 '<dir>' 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 "svn switch" directs you to run "svn cleanup".</p> <blockquote> <div><pre><code> wc/$ svn switch $SVNROOT/$project/branches/$ticket-xxx svn: Directory '<dir>/.svn' containing working copy admin area is missing wc/$ svn cleanup svn: '<dir>' 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! <dir>/<anotherdir> 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 ! . ! <dir> S <switched_things> ~ <dir>/<thing_that_is_now_unversioned> </code></pre></div> </blockquote> </div> <div class="h3" id="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? <a class="sectionlink" href="#long-paths" title="Link to this section">¶</a> </h3> <p>A careful examination of the Windows API documentation regarding <a href="https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath" >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 — 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> It does, as of Subversion 1.7.</p> </div> <div class="h3" id="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? <a class="sectionlink" href="#working-copy-format-change" title="Link to this section">¶</a> </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 — 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="https://issues.apache.org/jira/browse/SVN-2961" >issue #2961</a>, for example).</p> <p>Subversion 1.7.0 and newer will not upgrade working copies unless you explicitly ask them to do so. (Upgrading the working copies is, however, required; Subversion 1.7.0 cannot operate on working copies created or used by earlier Subversions.)</p> <p>Subversion 1.6.x and earlier automatically upgrade working copies when they first touch them. This 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="https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/change-svn-wc-format.py" >https://svn.apache.org/repos/asf/subversion/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. (It can downgrade 1.6.x working copies to formats usable by Subversion 1.4.x and 1.5.x, but cannot downgrade 1.7.x working copies.)</p> <p>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 class="h3" id="relocation-against-local-symbol"> <h3>I got an error saying "relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object" when building the Neon library on 64-bit Linux. <a class="sectionlink" href="#relocation-against-local-symbol" title="Link to this section">¶</a> </h3> <p>The Neon library, used for communication between a Subversion server and client over HTTP, is usually built as a static library. But it is subsequently linked into a different shared library. This causes an error during the build process on 64-bit AMD systems similar to this:</p> <blockquote> <div><pre><code> subversion-1.4.6/neon/src/.libs/libneon.a(ne_request.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /home/jrandom/subversion/subversion-1.4.6/neon/src/.libs/libneon.a: could not read symbols: Bad value </code></pre></div> </blockquote> <p>There was a <a href="https://svn.haxx.se/dev/archive-2006-09/0316.shtml">thread</a> on the developers' list about this.</p> <p>The solution is to supply the "--enable-shared" option to Subversion's configure script.</p> </div> <div class="h3" id="secure-connection-truncated"> <h3>Why am I getting an error saying "Could not read response body: Secure connection truncated" when doing a checkout from Apache? <a class="sectionlink" href="#secure-connection-truncated" title="Link to this section">¶</a> </h3> <p>In short, this error is representative of a class of problems which can occur when Apache erroneously believes that your Subversion client is no longer tending to the network connection it has made with Apache. Other error messages have been reported in similar circumstances, depending on whether or not SSL was in use for the connection, or when exactly Apache decided that the connection should be terminated.</p> <p>The Subversion client tries to keep working copies in a sane state at all times. One way it does this during checkouts is by squirreling away the pristine versions of checked-out files until all the files and subdirectories for a given directory have been fetched. Once all the data for a directory has been downloaded, the client "finalizes" that directory, copying the pristine versions of files out into the working area, diddling administrative data, and so on. While this directory finalization is happening, the client is focused on that task and is <em>not</em> tending to the checkout network stream. Sometimes — typically in situations where a versioned directory contains an abnormally large number of files, or a bunch of abnormally large files — the client can spend so much time finalizing a directory (and ignoring the network stream) that Apache thinks the client has gone away for good, so Apache terminates the connection. When the client finally turns its attention back to the network stream, it finds that the server has given up on the connection, and it reports this as an error.</p> <p>One workaround for this situation is to increase the amount of time Apache is willing to wait for a client to prove it is still listening to the network stream. You do this by adjusting upward the Apache <tt>Timeout</tt> configuration value. You are encouraged, however, to evaluate your data set. If having a huge number of files in a single directory is causing problems for you during checkouts, there is some chance that it will cause additional problems elsewhere, too. If it is possible for you to split your collection of files up into a few subdirectories with smaller file counts, this could prove universally beneficial.</p> </div> <div class="h3" id="self-tree-conflict"> <h3>Why am I getting a tree conflict upon update even though no one else has committed conflicting changes? <a class="sectionlink" href="#self-tree-conflict" title="Link to this section">¶</a> </h3> <p> When you commit, only the files/directories that are actually changed by the commit get their base revisions bumped to HEAD in the working copy. The other files/directories (possibly including the directory you committed from!) don't get their base revisions bumped, which means Subversion still considers them to be based on outdated revisions. See also <a href="#hidden-log">this question</a> and <a href="https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs.update-commit">this section of the Subversion book</a>. </p> <p> This can be confusing, in particular because of tree conflicts you can inflict upon yourself. E.g. if you add a file to a directory and commit, and then locally move that directory somewhere else, and then try to commit, this second commit will fail with an out-of-date error since the directory itself is still based on an out-of-date revision. When updating, a tree conflict will be flagged.</p> <p>Subversion has currently no way of knowing that you yourself just committed the change which caused the directory to be out-of-date during the second commit. And allowing an out-of-date directory to be committed may cause certain tree conflicts not to be detected, so Subversion can't allow you to do this. </p> <p>To avoid this problem, make sure to update your entire working copy before making structural changes such as deleting, adding, or moving files or directories.</p> </div> <div class="h3" id="ssl-error-336032856"> <h3>When performing Subversion operations over SSL, I get the error <tt>SSL handshake failed: SSL error code -1/1/336032856</tt>. <a class="sectionlink" href="#ssl-error-336032856" title="Link to this section">¶</a> </h3> <p>This can happen when the hostname reported by the server does not the match hostname given in the SSL certificate. Make sure your server configuration uses correct values for <tt>ServerName</tt> and <tt>NameVirtualHost</tt>. </p> <p> A client-side fix is to update OpenSSL to version 1.0.0d. See <a href="https://svn.haxx.se/dev/archive-2011-09/0047.shtml" >this post to the Subversion developer mailing list</a> for details. </p> </div> <div class="h3" id="error-validating-server-certificate"> <h3>I get <tt>"Error validating server certificate"</tt> error even though I configure the SSL certificates correctly in the server. <a class="sectionlink" href="faq.html#error-validating-server-certificate" title="Link to this section">¶</a> </h3> <p>This error occurs if the certificate issuer is not recognized as 'Trusted' by the SVN client. Subversion will ask you whether you trust the certificate and if you want to store this certificate.<br /> </p><br /> <pre style="margin-left: 40px;">$ svn info https://mysite.com/svn/repo<br />Error validating server certificate for 'https://mysite.com:443':<br />- The certificate is not issued by a trusted authority. Use the<br />fingerprint to validate the certificate manually!<br />Certificate information:<br />- Hostname: mysite.com<br />- Valid: from Wed, 18 Jan 2012 00:00:00 GMT until Fri, 18 Jan 2013<br />23:59:59 GMT<br />- Issuer: Google Inc, US<br />- Fingerprint:<br />34:4b:90:e7:e3:36:81:0d:53:1f:10:c0:4c:98:66:90:4a:9e:05:c9<br />(R)eject, accept (t)emporarily or accept (p)ermanently?</pre> <br /> <p>In some cases, even if you accept this by entering 'p' option, the next time you access SVN, the same error appears again. There can be multiple reasons. The problem may be your ~/.subversion directory has wrong permissions, so that each time you want to permanently add the credentials, svn actually cannot do so, and also doesn't inform you that it can't.<br /> </p> <p>This can be solved by either fixing the permissions with chmod 644 in</p> <pre style="margin-left: 40px;">~/.subversion/auth/svn.ssl.server</pre> <p>directory or by deleting the directory contents. If deleted, the directory gets populated automatically the next time you access the repository.</p> </div> <div class="h3" id="where-are-the-files"> <h3>After importing files to my repository, I don't see them in the repository directory. Where are they? <a class="sectionlink" href="#where-are-the-files" title="Link to this section">¶</a> </h3> <p>The files are in the repository; you can verify this by running commands such as <tt>svn ls -R</tt>, or by trying to checkout a working copy from the repository:</p> <pre> $ pwd /var/srv/repositories/foo $ ls -1 conf db format hooks locks README.txt $ svnlook youngest /var/srv/repositories/foo 1 $ svn ls file:///var/srv/repositories/foo trunk/ tags/ branches/ </pre> <p>The versioned files and directories are simply not stored on-disk in a tree format (like CVS repositories used to), but instead are stored in database files. The BDB backend uses Berkeley DB databases, and the FSFS backend uses both a custom file format and may in the future use SQLite databases.</p> </div> <div class="h3" id="copy-mergeinfo"> <h3>When does <tt>svn copy</tt> create <tt>svn:mergeinfo</tt> properties? <a class="sectionlink" href="#copy-mergeinfo" title="Link to this section">¶</a> </h3> <p>In general, to avoid some kinds of spurious merge conflicts, the following rules can be kept in mind:</p> <ul> <li>When copying/renaming a file or directory <em>within</em> the trunk or a branch, perform the copy/rename in a working copy. For renames, the working copy should <em>not</em> be a <a href="https://svnbook.red-bean.com/nightly/en/svn.basic.in-action.html#svn.basic.in-action.mixedrevs" >mixed-revision working copy</a>.</li> <li>When copying/renaming an entire branch, perform the copy/rename in the repository (i.e. via URLs).</li> </ul> <p>During copies where the source is a URL, and the target is either a URL or in a working copy, explicit mergeinfo is created on the copy target. This is done so that when a branch is created with <pre>svn copy ^/trunk ^/branches/mybranch</pre> and later an ancestrally unrelated subtree is copied into the branch using an invocation such as <pre>svn copy ^/branches/another-branch/foo ^/branches/mybranch/bar</pre> the directory <tt>/branches/mybranch/bar</tt> does not inherit mergeinfo from its parent <tt>/branches/mybranch</tt>. Mergeinfo inherited from the parent might not reflect the factually correct merge history of the new child.</p> <p>During copies where both the source and the target are within a working copy, no mergeinfo is created on the copy target (as of Subversion 1.5.5). This assumes the case where a new child is added on the trunk (or a branch), and this addition is merged to another branch which is kept in sync using periodic catch-up merges. In this case, the inherited mergeinfo of the branch's new child is correct, and the creation of explicit mergeinfo could cause spurious merge conflicts due to apparent, but factually inaccurate, differences in the child's and parent's merge histories.</p> <p>For additional details and discussion about this behaviour, see <a href="https://mail-archives.apache.org/mod_mbox/subversion-users/201011.mbox/%3CAANLkTin0xJwxg78rU-83QafOt-bcfgML_pB2AHWt2z1s%40mail.gmail.com%3E" >this post on the users mailing list</a>.</p> </div> <div class="h3" id="password-encodings"> <h3> Passwords which contain some special characters do not seem to be working? <a class="sectionlink" href="#password-encodings" title="Link to this section">¶</a> </h3> <p>Passwords which contain non-ASCII characters may not work reliably with the basic authentication mechanisms Subversion supports. This is due to potential character encoding differences between the client and server systems. See <a href="https://mail-archives.apache.org/mod_mbox/subversion-users/201204.mbox/%3C87obqpxnis.fsf@stat.home.lan%3E" >this mailing list post</a> for details.</p> <p>As a workaround, you can configure your Subversion server to use a single-sign-on mechanism, such as Kerberos or SSPI. See the <a href="https://httpd.apache.org/docs/" >Apache HTTPD server documentation</a> for details. If you are using svnserve, see the <a href="https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl" >'Using svnserve with SASL' chapter</a> in the Subversion book.</p> <p>When <a href="https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth" >using svnserve with SSH authentication</a> SSH keys can be used to work around this limitation of passwords.</p> </div> <div class="h3" id="dav-slow-copy"> <h3>Why does an HTTP(S) URL-to-URL copy or branch/tag operation take a long time? <a class="sectionlink" href="#dav-slow-copy" title="Link to this section">¶</a> </h3> <p>If you are seeing slow server-side copying (a.k.a. branching or tagging) with a Subversion repository served over HTTP(S), you might be running into <a href="https://issues.apache.org/jira/browse/SVN-4531" >issue 4531</a>. This problem is caused by a crawl of the “tree-to-copy” by httpd's mod_dav module on the server (giving the copy a performance cost of O(sizeof(tree)) instead of SVN's usual O(1) for branching/tagging). This behaviour is present in <b>Apache httpd version 2.2.25 (or higher)</b> and <b>2.4.6 (or higher)</b> – older versions of httpd are not affected. Branching/tagging a large tree may take several minutes because of this.</p> <p><b>This problem has been fixed in mod_dav_svn in Subversion 1.8.14.</b> You can also use the following workaround to make mod_dav skip the unnecessary work; add the following directives to the Apache configuration on the server, preferably only inside the Location blocks configured for SVN:</p> <pre> SetEnvIf Request_Method COPY method_is_copy RequestHeader set Depth 0 env=method_is_copy </pre> <p>This adds a request header "Depth" with value 0 to each COPY request. This makes mod_dav avoid the crawl of the tree being copied (yet still lets Subversion perform a normal recursive copy).</p> <p>See <a href="https://mail-archives.apache.org/mod_mbox/subversion-users/201503.mbox/%3CCAB84uBUp2kfJgZOadBDoRKHuQvTABeTO0PBUDV3m1fBcAijpQw@mail.gmail.com%3E" >this mailing list thread</a> for more details.</p> </div> <div class="h3" id="ssl-communication-error"> <h3>When performing Subversion operations over SSL, I get the error <tt>An error occurred during SSL communication</tt> <a class="sectionlink" href="#ssl-communication-error" title="Link to this section">¶</a> </h3> <p> SSL communication errors can have various reasons. You can use the openssl binary to debug the ssl connection. <pre> openssl s_client -connect example.com:443 -servername example.com </pre> If you use a client certificate, then you need to convert Subversion's client certificate from pkcs12 to pem first: <pre> openssl pkcs12 -in path/to/svn/cert.p12 -out cert.pem </pre> Then you can use: <pre> openssl s_client -connect example.com:443 -servername example.com -cert cert.pem </pre> If you are using ssl-authority-files in <tt>.subversion/servers</tt> to verify the server cert you can get <tt>s_client</tt> to do the same with the additional parameter: <pre> openssl s_client ... -CAfile path/to/authority.pem </pre> The <tt>s_client</tt> output may indicate what problem is occurring. </p> <p> For example, if <tt>s_client</tt> reports <pre> error setting certificate 140258270184704:error:140AB18E:SSL routines:SSL_CTX_use_certificate:ca md too weak:../ssl/ssl_rsa.c:303: </pre> then creating new CA keys with sha256 instead of md5 should solve the problem. </p> </div> </div> <div class="h2" id="developer-questions"> <h2>Developer questions: <a class="sectionlink" href="#developer-questions" title="Link to this section">¶</a> </h2> <p/> <div class="h3" id="ramdisk-tests"> <h3>How do I run the regression tests in a RAM disk? <a class="sectionlink" href="#ramdisk-tests" title="Link to this section">¶</a> </h3> See <a href="https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/README" >https://svn.apache.org/repos/asf/subversion/trunk/subversion/tests/cmdline/README</a> </div> <div class="h3" id="dynamic-exe-debugging"> <h3>How do I run a debugger on dynamic Subversion binaries without having to install them? <a class="sectionlink" href="#dynamic-exe-debugging" title="Link to this section">¶</a> </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>You can work around this by running gdb via the libtool command. The libtool command in execute mode will detect that the svn command is a libtool wrapper script and handle setting the appropriate environment variables and replace the script with the path to the real file before running gdb.. </p> <p>Your command line would look something like this:</p> <blockquote> <div><code>$ libtool execute gdb subversion/svn/svn</code></div> </blockquote> </div> <div class="h3" id="avoiding-compiler-inlining"> <h3>How do I run a debugger on Subversion binaries without compiler inlining obfuscating the source? <a class="sectionlink" href="#avoiding-compiler-inlining" title="Link to this section">¶</a> </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"> <h2>References: <a class="sectionlink" href="#references" title="Link to this section">¶</a> </h2> <p/> <div class="h3" id="http-methods"> <h3>What are all the HTTP methods Subversion uses? <a class="sectionlink" href="#http-methods" title="Link to this section">¶</a> </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>Note that this list may grow over time: Subversion 1.7+ started using the <tt>POST</tt> method when speaking to 1.7+ servers, and it's possible that Subversion 1.9+ might start using yet another method when talking to 1.9+ servers.</p> <p>The details of the protocol are documented here:</p> <a href="https://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/webdav-protocol" >https://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/webdav-protocol</a> </div> <div class="h3" id="bikeshed"> <h3>What's a 'bikeshed'? <a class="sectionlink" href="#bikeshed" title="Link to this section">¶</a> </h3> <p>See Poul-Henning Kamp's post to freebsd-hackers: <a href="https://docs.freebsd.org/en/books/faq/#bikeshed-painting">https://docs.freebsd.org/en/books/faq/#bikeshed-painting</a>. </p> </div> <div class="h3" id="pronounce"> <h3>How do you pronounce "Subversion"? <a class="sectionlink" href="#pronounce" title="Link to this section">¶</a> </h3> <p>Jim Blandy, who gave Subversion both its name and repository design, pronounces "Subversion" <a href="/pronunciation/index.html">"Subversion"</a>. </p> </div> <div class="h3" id="baton"> <h3>What's a 'baton'? <a class="sectionlink" href="#baton" title="Link to this section">¶</a> </h3> <p>Throughout Subversion's source code there are many references to 'baton' objects. These are just <tt>void *</tt> data structures 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"> <h3>What do you mean when you say that repository is 'wedged'? <a class="sectionlink" href="#def-wedged-repository" title="Link to this section">¶</a> </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 id="cvssv2"></div> <div class="h3" id="cvssv3"> <h3>What is CVSSv3 and what do the score and vector mean? <a class="sectionlink" href="#cvssv2" title="Link to this section">¶</a> </h3> <p>Subversion is using CVSSv3 in our <a href="/security/#advisories">security advisories</a> so you will see a CVSSv3 Base Score and Vector in the Severity section of our advisories. CVSSv3 is the current version of the Common Vulnerability Scoring System which is an open industry standard for assessing the severity of computer system security vulnerabilities. <a href="https://www.first.org/" >FIRST</a> maintains the <a href="https://www.first.org/cvss/user-guide" >documentation</a> for the standard. </p> <p>The score is a number in the range of 0 to 10 with less risky vulnerabilities scoring lower and more risky vunerabilities scoring higher. The score is calculated by determining the metrics of the vunerability and then calculating the score based on those metrics. If you want to understand how a score was determined you would need the vector and an understanding of the <a href="https://www.first.org/cvss/specification-document#CVSS-v3-1-Equations" >formula as specified by the standard</a>. </p> <p>The vector is an <a href="https://www.first.org/cvss/specification-document#Vector-String" >abbreviated description</a> of the metrics that apply to the vulnerability. </p> <p>CVSSv3 provides for 3 types of metrics and scores; base, temporal and environmental. The Subversion project will only ever provide the base score and metrics. As a project we cannot determine the environmental risks of the various installations so it is not possible for us to calculate the environmental metrics. The temporal metrics are for factors that may change over time. We do not update our advisories once published so it's not possible for us to track these changing values. </p> <p>Some vulnerabilities require specific configurations or environmental factors in order to be exploited. CVSSv3 specifies that the Access Complexity metric consider how common such a configuration is. As a result, a vulnerability that requires an unusual configuration will have a low score. The scores can help you prioritize how quickly you need to react to an advisory but as a result of the Access Complexity metric you should still consider how the vulnerability impacts your installation. </p> <p>When calculating the Availability Impact metric of server vulnerabilities the Subversion project will use the value of Complete within the context of Subversion and not the host system. For example when considering a Denial of Service attack the Availability Impact metric will be calculated as High if the vulnerability allows an attacker to make the Subversion server completely inaccessible. On the other hand if the attack only made the Subversion server slow or limited the number of successful connections it would be rated as Low. </p> <p>When calculating the Integrity Impact metric of server vulnerabilities the Subversion project will use the value of High when history of the Subversion repositories may be changed or when the ability to modify any file on the host system occurs. The ability to change any file (while leaving the appropriate history trail) in violation of any authentication or authorization requirements will be treated as Low. </p> <p>When calculating the Confidentiality Impact metric of server vulnerabilities the Subversion project will use the value of High when all files in the repository may be read regardless of any authentiation or authorizaiton requirements. If only some files may be read it will be considered Low. </p> <p>As a result of how we calculate these impact metrics you may see advisories in vulnerability databases or vendor advisories that have a different score. For instance an Linux distribution that provides a binary package of Subversion may score the full exposure of the contents of the Subversion repository hosted on the system as only a Low Confidentiality Impact, resulting in a lower score. </p> </div> </div> <hr/> <div class="h1" id="deprecated-faq"> <h1>Deprecated FAQ</h1> <div class="h2"> <h2>Table of Contents</h2> <h4>Troubleshooting:</h4> <ul> <li><a href="#digest-auth">Why doesn't HTTP Digest auth work?</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> </ul> <h4>BDB questions:</h4> <ul> <li><a href="#divining-bdb-version">How do I determine which version of Berkeley DB a repository is using?</a></li> <li><a href="#bdblogs">Why is my repository taking up so much disk space?</a></li> <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="#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="#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="#bdb43-upgrade">After upgrading to Berkeley DB 4.3 or later, I'm seeing repository errors.</a></li> <li><a href="#readonly">Why do read-only operations still need repository write access?</a></li> </ul> </div> <hr/> <div class="h2" id="deprecated-troubleshooting"> <h2>Troubleshooting (deprecated): <a class="sectionlink" href="#deprecated-troubleshooting" title="Link to this section">¶</a> </h2> <div class="h3" id="digest-auth"> <h3>Why doesn't HTTP Digest auth work? <a class="sectionlink" href="#digest-auth" title="Link to this section">¶</a> </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="https://bz.apache.org/bugzilla/show_bug.cgi?id=25040" >https://bz.apache.org/bugzilla/show_bug.cgi?id=25040</a>. You may also want to read over <a href="https://issues.apache.org/jira/browse/SVN-1608" >https://issues.apache.org/jira/browse/SVN-1608</a> to see if the description there matches your symptoms. </p> </div> <div class="h3" id="windows-xp-server"> <h3>Under Windows XP, the Subversion server sometimes seems to send out corrupted data. Can this really be happening? <a class="sectionlink" href="#windows-xp-server" title="Link to this section">¶</a> </h3> <p>You need to install Window XP Service Pack 1.</p> </div> </div> <div class="h2" id="bdb-questions"> <h2>BDB questions: <a class="sectionlink" href="#bdb-questions" title="Link to this section">¶</a> </h2> <div class="h3" id="divining-bdb-version"> <h3>How do I determine which version of Berkeley DB a repository is using? <a class="sectionlink" href="#divining-bdb-version" title="Link to this section">¶</a> </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><number></i></tt>". Here is an example using Mac OS X hexdump: "<tt>hexdump -s12 -n8 -x log.<i><number></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> <tr><td>12 (0x0000000c)</td><td>4.5</td></tr> <tr><td>13 (0x0000000d)</td><td>4.6</td></tr> </table> </div> <div class="h3" id="bdblogs"> <h3>Why is my repository taking up so much disk space? <a class="sectionlink" href="#bdblogs" title="Link to this section">¶</a> </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="https://svn.haxx.se/users/archive-2004-07/1662.shtml" >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 <code>DB_LOG_AUTOREMOVE</code> flag in the Berkeley DB manual located under docs/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE on the <a href="https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html"> Berkeley DB 4.2.x download package</a>.</p> </div> <div id="permissions"></div> <div class="h3" id="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? <a class="sectionlink" href="#stuck-bdb-repos" title="Link to this section">¶</a> </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"> <h3>Every time I try to access my repository, the process just hangs. Is my repository corrupt? <a class="sectionlink" href="#bdb-recovery" title="Link to this section">¶</a> </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 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->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 the Berkeley DB db_recover documentation located under docs/utility/db_recover.html on the <a href="https://www.oracle.com/technetwork/database/database-technologies/berkeleydb/downloads/index-082944.html"> Berkeley DB 4.2.x download package</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"> <h3>My repository keeps giving errors saying "Cannot allocate memory". What should I do? <a class="sectionlink" href="#bdb-cannot-allocate-memory" title="Link to this section">¶</a> </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="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. <a class="sectionlink" href="#db3db4" title="Link to this section">¶</a> </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"> <h3>I'm getting "Function not implemented" errors on Red Hat 9, and nothing works. How do I fix this? <a class="sectionlink" href="#redhat-db" title="Link to this section">¶</a> </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="https://svn.haxx.se/users/archive-2004-03/0488.shtml"> https://svn.haxx.se/users/archive-2004-03/0488.shtml </a> for details. </p> </div> <div class="h3" id="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? <a class="sectionlink" href="#bdb41-tabletype-bug" title="Link to this section">¶</a> </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.apache.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 > 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 < copies.dump</tt></li> <li><tt>svnadmin dump .. > ../../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="bdb43-upgrade"> <h3>After upgrading to Berkeley DB 4.3 or later, I'm seeing repository errors. <a class="sectionlink" href="#bdb43-upgrade" title="Link to this section">¶</a> </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 recover /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 list-unused-dblogs /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="readonly"> <h3>Why do read-only operations still need repository write access? <a class="sectionlink" href="#readonly" title="Link to this section">¶</a> </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="https://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends.fsfs" >FSFS backend</a> does not exhibit this behaviour.</p> </div> </div> </div> </div> </body> </html>