www/faq.html - subversion - Git at Google


            
            <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

            
            "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

            
            <html>

            
            <head>

            
            <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>

            
            <style type="text/css"> /* <![CDATA[ */

            
              @import "tigris-branding/css/tigris.css";

            
              @import "tigris-branding/css/inst.css";

            
              /* ]]> */</style>

            
            <link rel="stylesheet" type="text/css" media="print"

            
              href="tigris-branding/css/print.css"/>

            
            <script type="text/javascript" src="tigris-branding/scripts/tigris.js"></script>

            
            <title>Subversion FAQ</title>

            
            </head>


            <body>

            
            <div class="app">


            <h1>Subversion FAQ</h1>


            <![CDATA[=========================================================]]>


            <div class="h2"><!-- no 'id' or 'title' attribute for TOC -->

            
            <h2>Table of Contents</h2>


            <h4>General questions:</h4>

            
            <ul>

            
            <li><a href="#why">Why does this project exist?</a></li>

            
            <li><a href="#collab">Is Subversion proprietary?  I heard that it

            
                belongs to CollabNet.</a></li>

            
            <li><a href="#stable">Is Subversion stable enough for me to use for my

            
                own projects?</a></li>

            
            <li><a href="#interop">What is Subversion's client/server interoperability

            
                policy?</a></li>

            
            <li><a href="#portability">What operating systems does Subversion run

            
                on?</a></li>

            
            <li><a href="#filesystem">What's all this about a new filesystem?  Is

            
                it like ext2?</a></li>

            
            <li><a href="#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>

            
            </ul>


            <h4>How-to:</h4>

            
            <ul>

            
            <li><a href="#co-svn">How do I check out the Subversion code?</a></li>

            
            <li><a href="#repository">How do I create a repository?  How do I

            
                import data into it?</a></li>

            
            <li><a href="#cvs2svn">How do I convert an existing CVS repository

            
                into a Subversion repository?</a></li>

            
                <li><a href="#proxy">What if I'm behind a proxy?</a></li>

            
            <li><a href="#paranoid">My admins don't want me to have a HTTP server for

            
                Subversion.  What can I do if I still want remote usage?</a></li>

            
            <li><a href="#multi-proj">How do I manage several different projects

            
                under Subversion?</a></li>

            
            <li><a href="#multi-merge">How do I merge two completely separate repositories?</a></li>

            
            <li><a href="#nfs">Should I store my repository / working copy on a

            
                NFS server?</a></li>

            
            <li><a href="#bdblogs">Why is my repository taking up so much disk space?</a></li>

            
            <li><a href="#reposperms">How do I set repository permissions correctly?</a></li>

            
            <li><a href="#readonly">Why do read-only operations still need repository write access?</a></li>

            
            <li><a href="#removal">How do I completely remove a file from the repository's history?</a></li>

            
            <li><a href="#change-log-msg">How do I change the log message for a revision

            
                after it's been committed?</a></li>

            
            <li><a href="#patch">How do I submit a patch for Subversion?</a></li>

            
            <li><a href="#in-place-import">How can I do an in-place 'import'

            
                (i.e. add a tree to subversion such that the original data becomes

            
                a working copy directly)?</a></li>

            
            <li><a href="#dumpload">What is this "dump/load cycle" people

            
                sometimes talk about when upgrading a Subversion server?</a></li>

            
            <li><a href="#sspi">How do I allow clients to authenticate against a

            
                Windows domain controller using SSPI Authentication?</a></li>

            
            <li><a href="#adm-dir">I don't like the ".svn" directory name, and

            
                prefer "SVN" or something else.  How do I change it?</a></li>

            
            <li><a href="#case-change">How do I change the case of a filename?</a></li>

            
            <li><a href="#merge-using-tags">I can't use tags to merge changes from a

            
                branch into the trunk like I used to with CVS, can I?</a></li>

            
            <li><a href="#version-value-in-source">Why doesn't the $Revision$

            
              keyword do what I want?  It expands to the file's last-changed

            
              revision, but I want something that will expand to the file's

            
              current revision.</a></li>

            
            <li><a href="#log-in-source">Does Subversion have a keyword which behaves

            
              like $Log$ in CVS?</a></li>

            
            <li><a href="#ignore-commit">I have a file in my project that every

            
            developer must change, but I don't want those local mods to ever be

            
            committed.  How can I make 'svn commit' ignore the file?</a></li>

            
            <li><a href="#ssh-auth-cache">When I access a repository using

            
            svn+ssh, my password is not cached in ~/.subversion/auth/.  How do

            
            I avoid having to type it so often?</a></li>

            
            <li><a href="#ssh-svnserve-location">My

            
            <tt>svnserve</tt> binary is in a directory that isn't on my

            
            users' default <tt>PATH</tt>s, they use svn+ssh, and I can't figure

            
            out how to modify their <tt>PATH</tt> so that they can run <tt>svnserve</tt>.</a></li>

            
            <li><a href="#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="#divining-bdb-version">How do I determine which version of

            
            Berkeley DB a repository is using?</a></li>

            
            <li><a href="#website-auto-update">I'm managing a website in my

            
            repository.  How can I make the live site automatically update after

            
            every commit?</a></li>

            
            <li><a href="#single-file-checkout">How do I check out a single

            
            file?</a></li>

            
            <li><a href="#wc-change-detection">How do I detect adds, deletes,

            
            copies and renames in a working copy after they've already

            
            happened?</a></li>

            
            <li><a href="#svnserve-win-service">How do I run svnserve as a service

            
            on Windows?</a></li>

            
            <li><a href="#bdb-fsfs-convert">How do I convert my repository from using BDB

            
            to FSFS or from FSFS to BDB?</a></li>

            
            <li><a href="#binary-files">How does Subversion handle binary files?</a></li>

            
            </ul>


            <h4>Troubleshooting:</h4>

            
            <ul>

            
            <li><a href="#stuck-bdb-repos">My repository seems to get stuck all the

            
                time, giving me errors about needing recovery (DB_RUNRECOVERY).

            
                What could be the cause?</a></li>

            
            <li><a href="#bdb-recovery">Every time I try to access

            
                my repository, the process just hangs.  Is my repository

            
                corrupt?</a></li>

            
            <li><a href="#bdb-cannot-allocate-memory">My repository keeps giving

            
                errors saying "Cannot allocate memory".  What should I do?</a></li>

            
            <li><a href="#wedged-wc">Every time I try to run a svn

            
                command, it says my working copy is locked.  Is my working copy

            
                corrupt?</a></li>

            
            <li><a href="#wc-out-of-date">I'm trying to commit, but Subversion says my

            
                working copy is out of date?</a></li>

            
            <li><a href="#unrecognized-url-error">I just built the distribution

            
                binary, and when I try to check out Subversion, I get an error

            
                about an "Unrecognized URL scheme."  What's up with that?</a></li>

            
            <li><a href="#db-recover">I'm getting errors finding or opening a repository,

            
                but I know my repository URL is correct.  What's wrong?</a></li>

            
            <li><a href="#configure-sed-error">When I run `<tt>configure</tt>', I

            
                get errors <tt>subs-1.sed&nbsp;line&nbsp;38:&nbsp;Unterminated&nbsp;`s'&nbsp;command</tt>.  What's wrong?</a></li>

            
            <li><a href="#linux-bdb42-build">I'm having trouble building

            
                Subversion under *NIX with BerkeleyDB 4.2 What should I do?</a></li>

            
            <li><a href="#windows-mod_dav_svn-build">I'm getting errors trying to build

            
                Subversion 1.2 on Windows &mdash; mod_dav_svn won't build.</a></li>

            
            <li><a href="#windows-msvc-build">I'm having trouble building

            
                Subversion under Windows with MSVC++ 6.0.  What should I do?</a></li>

            
            <li><a href="#windows-drive-letter">How can I specify a Windows drive letter in

            
            a <tt>file:</tt> URL?</a></li>

            
            <li><a href="#write-over-dav">I'm having trouble doing write

            
                operations to a Subversion repository over a network.</a></li>

            
            <li><a href="#vs-asp-net">VS.NET/ASP.NET seems to have a problem with

            
                the ".svn" directory name.  What should I do?</a></li>

            
            <li><a href="#windows-xp-server">Under Windows XP, the Subversion

            
                server sometimes seems to send out corrupted data.  Can this really be

            
                happening?</a></li>

            
            <li><a href="#ethereal">What is the best method of doing a network

            
                trace of the conversation between a Subversion client and server?</a></li>

            
            <li><a href="#revert">Why does the <tt>svn revert</tt> require an

            
                explicit target?  Why is it not recursive by default?  These

            
                behaviors differ from almost all the other subcommands.</a></li>

            
            <li><a href="#db3db4">When I start Apache, mod_dav_svn complains about

            
                a "bad database version", that it found db-3.X, rather than

            
                db-4.X.</a></li>

            
            <li><a href="#redhat-db">I'm getting "Function not implemented" errors on

            
                RedHat 9, and nothing works.  How do I fix this?</a></li>

            
            <li><a href="#no-author">Why does SVN log say "(no author)" for files

            
                committed or imported via Apache (ra_dav)?</a></li>

            
            <li><a href="#windows-access-denied">I'm getting occasional "Access Denied"

            
                errors on Windows.  They seem to happen at random.  Why?</a></li>

            
            <li><a href="#freebsd-hang">On FreeBSD, certain operations (especially

            
                svnadmin create) sometimes hang.  Why?</a></li>

            
            <li><a href="#http-301-error">I can see my repository in a web browser, but

            
                'svn checkout' gives me an error about "301 Moved Permanently".

            
                What's wrong?</a></li>

            
            <li><a href="#no-copy-history">I'm trying to look at an old version of my

            
                file, but svn says something about "path not found".  What's going

            
                on?</a></li>

            
            <li><a href="#digest-auth">Why doesn't HTTP Digest auth work?</a></li>

            
            <li><a href="#xlc-compile">Compiling with xlc on AIX, I get compilation

            
                errors.  What's wrong?</a></li>

            
            <li><a href="#nonrecursive-checkout">I checked out a directory

            
                non-recursively (with -N), and now I want to make certain

            
                subdirectories "appear".  But <tt>svn up subdir</tt> doesn't

            
                work.</a></li>

            
            <li><a href="#mod_dav_svn-win32">I am trying to use mod_dav_svn

            
                with Apache on Win32 and I'm getting an error saying that the

            
                module cannot be found, yet the mod_dav_svn.so file is right

            
                there in <tt>\Apache\modules.</tt></a></li>

            
            <li><a href="#hook-debugging">Why aren't my repository hooks working?</a></li>

            
            <li><a href="#diff-cmd">Why does my --diff-cmd complain about '-u'?

            
                I tried to override it with --extensions, but it's not working.</a></li>

            
            <li><a href="#plaintext-passwords">Ahhh!  I just discovered that my

            
                Subversion client is caching passwords in plain-text on disk!

            
                AHHH!</a></li>

            
            <li><a href="#bdb41-tabletype-bug">I'm getting the error "svn: bdb: call

            
                implies an access method which is inconsistent with previous

            
                calls". How do I fix this?</a></li>

            
            <li><a href="#hotcopy-large-repos">I can't hotbackup my repository, svnadmin

            
                fails on files larger than 2Gb!</a></li>

            
            <li><a href="#hidden-log">I cannot see the log entry for the file

            
                I just committed.  Why?</a></li>

            
            <li><a href="#bdb43-upgrade">After upgrading to Berkeley DB

            
                4.3, I'm seeing repository errors.</a></li>

            
            <li><a href="#tiger-apr-0.9.6">Why do I get occasional, seemingly

            
                inconsistent errors checking out over http:// from a repository

            
                running on MacOS X 10.4 (Tiger)?</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>

            
            </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="#baton">What's a 'baton'?</a></li>

            
            <li><a href="#def-wedged-repository">What do you mean when you say that

            
                repository is 'wedged'?</a></li>

            
            </ul>


            </div>


            <![CDATA[=========================================================]]>


            <hr/>


            <div class="h2" id="general-questions" title="general-questions">

            
            <h2>General questions:</h2>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="why" title="why">

            
            <h3>Why does this project exist?</h3>


            <p>To take over the CVS user base.  Specifically, we're writing a new

            
            version control system that is very similar to CVS, but fixes many

            
            things that are broken.  See our front page.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="collab" title="collab">

            
            <h3>Is Subversion proprietary?  I heard that it

            
            belongs to CollabNet.</h3>


            <p>No, Subversion is open source / free software.  CollabNet pays the

            
            salaries of several full-time developers, and holds the copyright on

            
            the code, but that copyright is <a

            
            href="http://subversion.tigris.org/project_license.html">an

            
            Apache/BSD-style license</a>

            
            which is fully compliant with the <a

            
            href="http://www.debian.org/social_contract#guidelines">Debian Free

            
            Software Guidelines</a>.  In other words, you are free to download,

            
            modify, and redistribute Subversion as you please; no permission from

            
            CollabNet or anyone else is required.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="stable" title="stable">

            
            <h3>Is Subversion stable enough for me to use for my

            
            own projects?</h3>


            <p>Yes, absolutely.  It's ready for prime-time production.</p>


            <p>Subversion has been in development since 2000, and became

            
            self-hosting after one year.  A year later when we declared "alpha",

            
            Subversion was already being used by dozens of private developers and

            
            shops for real work.  After that, it was two more years of bugfixing

            
            and stabilization until we reached 1.0.  Most other projects probably

            
            would have called the product "1.0" much earlier, but we deliberately

            
            decided to delay that label as long as possible.  We were aware that

            
            many people were waiting for a 1.0 before using Subversion, and had

            
            very specific expectations about the meaning of that label. So we

            
            stuck to that same standard.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="interop" title="interop">

            
            <h3>What is Subversion's client/server

            
                interoperability policy?</h3>


            <p>The client and server are designed to work as long as they aren't

            
             more than one major release version apart.  For example, any 1.X

            
             client will work with a 1.Y server.  However, if the client and

            
             server versions don't match, certain features may not be available.</p>


            <p>See the client/server interoperability policy is documented in the

            
             "Compatibility" section of the <a

            
             href="http://svn.collab.net/repos/svn/trunk/HACKING">HACKING

            
             file</a>.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="portability" title="portability">

            
            <h3>What operating systems does Subversion run

            
                on?</h3>


            <p>All modern flavors of Unix, Win32, BeOS, OS/2, MacOS X.</p>


            <p>Subversion is written in ANSI C and uses APR, the <a

            
            href="http://apr.apache.org">Apache Portable Runtime</a> library, as a

            
            portability layer.  The Subversion client will run anywhere APR runs,

            
            which is most places.  The Subversion server (i.e., the repository

            
            side) is the same, except that it will not host a BDB repository

            
            on Win9x platforms (Win95/Win98/WinME), because <a

            
            href="http://www.sleepycat.com">Berkeley DB</a> 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>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="filesystem" title="filesystem">

            
            <h3>What's all this about a new filesystem?  Is

            
            it like ext2?</h3>


            <p>No.  The "Subversion Filesystem" is not a kernel-level filesystem

            
            that one would install in an operating system.  Instead, it is

            
            Subversion's repository interface, which is a "versioned filesystem"

            
            in the sense that it stores a directory tree whose state is remembered

            
            from revision to revision.  Writing programs to access the repository

            
            is similar to writing programs that use other filesystem APIs.  The

            
            main difference is that this particular filesystem doesn't lose data

            
            when written to; old tree states can be retrieved as easily the most

            
            recent state.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="apache-extension" title="apache-extension">

            
            <h3>I heard that Subversion is an Apache

            
            extension?  What does it use for servers?</h3>


            <p>No.  Subversion is a set of libraries.  It comes with a

            
            command-line client that uses them.  There are two different

            
            Subversion server processes: either <b>svnserve</b>, which is small

            
            standalone program similar to cvs pserver, or Apache <b>httpd-2.0</b>

            
            using a special <b>mod_dav_svn</b> module.  <b>svnserve</b> speaks a

            
            custom protocol, while <b>mod_dav_svn</b> uses WebDAV as its network

            
            protocol.  See <a

            
            href="http://svnbook.red-bean.com/html-chunk/ch06.html">chapter 6</a>

            
            in the Subversion book to learn more.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="need-apache" title="need-apache">

            
            <h3>Does this mean I have to set up Apache to

            
            use Subversion?</h3>


            <p>The short answer:  no.</p>


            <p>The long answer:  if you just want to access a repository, then you

            
             only need to build a Subversion client.  If you want to <b>host</b> a

            
             networked repository, then you need to set up either Apache2 or an

            
             "svnserve" server.</p>


            <p>For more details about setting up a network accessible Subversion

            
            server, see <a

            
            href="http://svnbook.red-bean.com/html-chunk/ch06.html">chapter 6</a>

            
            in the Subversion book.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="multiple-apachim" title="multiple-apachim">

            
            <h3>I run Apache 1.x right now, and can't

            
            switch to Apache 2.0 just to serve Subversion repositories.

            
            Does that mean I can't run a Subversion server?</h3>


            <p>No, you can run <b>svnserve</b> as a Subversion server.  It works

            
            extremely well.</p>


            <p>If you want WebDAV and all the other "goodies" that come with the

            
            Apache server, then yes, you'll need Apache 2.0.  It's always an

            
            option to run Apache 2.0 on a different port while continuing to run

            
            Apache 1.x on port 80.  Different versions of Apache can happily

            
            coexist on the same machine.  Just change the <tt>Listen</tt>

            
            directive in httpd.conf from "<tt>Listen&nbsp;80</tt>" to

            
            "<tt>Listen&nbsp;8080</tt>" or whatever port number you want, and make

            
            sure to specify that port when you publish your repository URL (e.g.,

            
            <tt>http://svn.mydomain.com:8080/repos/blah/trunk/</tt>).</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="feature-x" title="feature-x">

            
            <h3>Why don't you do X, just like SCM system Y?</h3>


            <p>We aren't attempting to break new ground in SCM systems, nor are we

            
            attempting to imitate all the best features of every SCM system out

            
            there.  We're trying to replace CVS.  See the first question.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="globalrev" title="globalrev">

            
            <h3>Why does the entire repository share the

            
                same revision number? I want each of my projects to have their

            
                own revision numbers.</h3>

            
            <p>

            
            The global revision number attached to the repository as a whole is

            
            meaningless from a user's perspective. It's an internal mechanism that

            
            accomplishes the goal of the underlying schema design. It just so

            
            happens to be exposed so that the user's interface can sometimes be a

            
            little more convenient than always having to type obnoxiously long

            
            date/time strings.

            
            </p>


            <p>

            
            The revision number is only relevant to the repository, and user

            
            convenience. It has <b>no</b> impact on any other factor of what you

            
            store in the repository.  Repository revision number bumps aren't

            
            nearly useful enough to be an accurate indication of the real rate of

            
            change of a given code base.  There are other more complicated ways to

            
            get a much better picture of a code-base's rate of change.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="changesets" title="changesets">

            
            <h3>Does Subversion have Changesets?</h3>


            <p>The question is a bit loaded, because everyone seems to have a

            
            slightly different definition of "changeset", or a least a slightly

            
            different expectation of what it means for a version control system to

            
            have "changeset features".</p>


            <p>For the purposes of this discussion, here's a simple definition of

            
            changeset: it's a collection of changes with a unique name.  The

            
            changes might include textual edits to file contents, modifications to

            
            tree structure, or tweaks to metadata.  In more common speak, a

            
            changeset is just a patch with a name you can refer to.</p>


            <p>Subversion manages versioned trees as first order objects (the

            
            repository is an array of trees), and the changesets are things that

            
            are derived (by comparing adjacent trees.)  Systems like Arch or

            
            Bitkeeper are built the other way around: they're designed to manage

            
            changesets as first order objects (the repository is a bag of

            
            patches), and trees are derived by composing sets of patches

            
            together.</p>


            <p>Neither philosophy is better in absolute terms: the debate goes

            
            back at least 30 years.  The two designs are better or worse for

            
            different types of software development.  We're not going to discuss

            
            that here.  Instead, here's an explanation of what you can do with

            
            Subversion.</p>


            <p>In Subversion, a global revision number 'N' names a tree in the

            
            repository: it's the way the repository looked after the Nth commit.

            
            It's also the name of an implicit changeset: if you compare tree N

            
            with tree N-1, you can derive the exact patch that was committed.</p>


            <p>For this reason, it's easy to think of "revision N" as not just a

            
            tree, but a changeset as well.  If you use an issue tracker to manage

            
            bugs, you can use the revision numbers to refer to particular patches

            
            that fix bugs -- for example, "this issue was fixed by revision 9238."

            
            Somebody can then run 'svn log -r9238' to read about the exact

            
            changeset which fixed the bug, and run 'svn diff -r9237:9238' to see

            
            the patch itself.  And svn's merge command also uses revision numbers.

            
            You can merge specific changesets from one branch to another by naming

            
            them in the merge arguments: 'svn merge -r9237:9238 branchURL' would

            
            merge changeset #9238 into your working copy.</p>


            <p>This is nowhere near as complicated as a system built around

            
            changesets as primary objects, but it's still a vast convenience over

            
            CVS.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="release" title="release">

            
            <h3>When's the next release?</h3>


            <p>See our status page, <a

            
            href="http://subversion.tigris.org/project_status.html">

            
            http://subversion.tigris.org/project_status.html</a>.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="symlinks" title="symlinks">

            
            <h3>Does Subversion support symlinks?</h3>


            <p>Subversion 1.1 (and later) has the ability to put a symlink under

            
            version control, via the usual <tt>svn add</tt> command.</p>


            <p>Details: the Subversion repository has no internal concept of a

            
            symlink.  It stores a "versioned symlink" as an ordinary file with an

            
            'svn:special' property attached.  The svn client (on unix) sees the

            
            property and translates the file into a symlink in the working copy.

            
            Win32 has no symlinks, so a win32 client won't do any such

            
            translation: the object appears as a normal file.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="logo" title="logo">

            
            <h3>I need a high resolution version of the Subversion logo,

            
                where can I get it?</h3>


            <p>Vectorized versions of the Subversion logo are available in the <a

            
            href="http://svn.collab.net/repos/svn/trunk/www">logo directory of the www

            
            tree</a> of the <a href="http://svn.collab.net/repos/svn/trunk">Subversion

            
            repository</a>.</p>


            <p>Specifically, an <a

            
            href="http://svn.collab.net/repos/svn/trunk/www/logo/subversion_logo.eps">EPS

            
            version</a>, as well as an <a

            
            href="http://svn.collab.net/repos/svn/trunk/www/logo/subversion_logo.ai">Adobe

            
            Illustrator document</a> are available.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="more-information" title="more-information">

            
            <h3>I have other questions.  Where can I get more information?</h3>


            <p>Please send your questions or concerns to the Subversion Users <a

            
            href="mailto:users@subversion.tigris.org">mailing list</a>.  Alternatively,

            
            several Subversion users and developers can usually be contacted via IRC on

            
            channel #svn on irc.freenode.net.</p>


            </div>


            <![CDATA[=========================================================]]>


            </div>


            <div class="h2" id="how-to" title="how-to">

            
            <h2>How-to:</h2>

            
            <p/>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="co-svn" title="co-svn">

            
            <h3>How do I check out the Subversion code?</h3>

            
            <p>Use the subversion client:</p>

            
            <pre>

            
            	$ svn co http://svn.collab.net/repos/svn/trunk subversion

            
            </pre>

            
            <p>That will check out a copy of the Subversion source tree into a

            
            directory named subversion on your local machine.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="repository" title="repository">

            
            <h3>How do I create a repository?  How do I

            
            import data into it?</h3>


            <p>See <a

            
            href="http://svn.collab.net/repos/svn/trunk/README">

            
            http://svn.collab.net/repos/svn/trunk/README</a>;  specifically, look

            
            at section IV, the "Quickstart Guide".</p>


            <p>For even more detail, read chapter 5 in <a

            
             href="http://svnbook.red-bean.com">The Subversion Book</a>.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="cvs2svn" title="cvs2svn">

            
            <h3>How do I convert an existing CVS repository

            
                into a Subversion repository?</h3>


            <p>Members of the Subversion development community created and

            
            maintain a tool called cvs2svn.  You can find it at <a

            
            href="http://cvs2svn.tigris.org/">http://cvs2svn.tigris.org/</a>.  Be

            
            sure to read the <a

            
            href="http://svn.collab.net/repos/cvs2svn/trunk/README">README</a>.

            
            </p>


            <p>If cvs2svn.py does not work for you, (e.g. your repository

            
            causes it to crash, or it doesn't deal with branches and tags

            
            quite how you would like), there are at least two other

            
            conversion utilities you can try.  These have different features

            
            (and possibly different bugs):</p>


            <ul>


            <li>One based on <a

            
            href="http://public.perforce.com/public/revml/index.html">VCP</a>

            
            written by Chia-liang Kao can be found on <a

            
            href="http://search.cpan.org/perldoc?VCP::Dest::svk">CPAN</a>.</li>


            <li>refinecvs written by Lev Serebryakov is at <a

            
            href="http://lev.serebryakov.spb.ru/refinecvs/"

            
            >http://lev.serebryakov.spb.ru/refinecvs/</a>.</li>


            </ul>


            <p>See also the <a href="project_links.html">Subversion links</a>

            
            page.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="proxy" title="proxy">

            
            <h3>What if I'm behind a proxy?</h3>


            <p>The Subversion client can go through a proxy, if you configure it

            
            to do so.  First, edit your "servers" configuration file

            
            to indicate which proxy to use. The files location depends on your

            
            operating system. On Linux or Unix it is located in the directory

            
            "~/.subversion". On Windows it is in "%APPDATA%\Subversion". (Try

            
            "echo %APPDATA%", note this is a hidden directory.)</p>


            <p>There are comments in the file explaining what to do.  If you don't

            
            have that file, get the latest Subversion client and run any command;

            
            this will cause the configuration directory and template files to be

            
            created.</p>


            <p>Older versions of Subversion, including the 0.14.3 bootstrap

            
            tarball, use the file ~/.subversion/proxies to define the proxy

            
            settings.  This file is ignored by the current version of

            
            Subversion.</p>


            <p>Next, you need to make sure the proxy server itself supports all

            
            the HTTP methods Subversion uses.  Some proxy servers do not support

            
            these methods by default: PROPFIND, REPORT, MERGE, MKACTIVITY,

            
            CHECKOUT.  In general, solving this depends on the particular proxy

            
            software.  For Squid, the config option is</p>


            <pre>

            
               #  TAG: extension_methods

            
               #       Squid only knows about standardized HTTP request methods.

            
               #       You can add up to 20 additional "extension" methods here.

            
               #

            
               #Default:

            
               # none

            
               extension_methods REPORT MERGE MKACTIVITY CHECKOUT

            
            </pre>


            <p>(Squid 2.4 and later already knows about PROPFIND.)</p>


            <p>See also "<a href="#http-methods">What are all the HTTP methods

            
            Subversion uses?</a>" for advice on additional HTTP methods to allow

            
            through your proxy.</p>


            <p>If it's difficult or impossible to get the proxy to allow

            
            Subversion traffic, but you want to check out the Subversion sources,

            
            you may be able to go around the proxy.  Some proxies that filter port

            
            80 nevertheless allow anything on port 81.  For this reason, the

            
            <tt>svn.collab.net</tt> repository server listens on port 81 as well

            
            as on port 80.  Try:</p>


            <pre>

            
               svn checkout http://svn.collab.net:81/repos/svn/trunk subversion

            
            </pre>


            <p>and maybe the proxy will let you through.  Another strategy is to

            
            attempt the checkout over SSL, which many proxies allow:</p>


            <pre>

            
               svn checkout https://svn.collab.net/repos/svn/trunk subversion

            
            </pre>


            <p>Of course, your svn client will have to have been built with ssl

            
            support; just pass <tt>--with-ssl</tt> to subversion's

            
            <tt>./configure</tt> script.  You can check to see whether the 'https'

            
            scheme is supported by running <tt>svn --version</tt>.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="paranoid" title="paranoid">

            
            <h3>My admins don't want me to have a HTTP server for

            
                Subversion.  What can I do if I still want remote usage?</h3>


            <p>A simple option is to use the <b>svnserve</b> server instead of

            
            Apache.  See <a

            
            href="http://svnbook.red-bean.com/html-chunk/ch06.html">chapter 6</a>

            
            in the Subversion book for details.</p>


            <p>However, if your admins don't want you to run Apache, it's very

            
            likely they don't want you to run a custom server process on port 3690

            
            either!  So the rest of this answer assumes that your admins

            
            <i>are</i> okay with you using an existing SSH infrastructure.</p>


            <p>If you previously used CVS, you may have used SSH to login to the

            
            CVS server.  The ra_svn Subversion access method is the equivalent way

            
            of doing this with Subversion.  Just use the "svn+ssh" prefix to your

            
            Subversion repository URL.</p>

            
            <pre>

            
            $ svn checkout svn+ssh://your.domain.com/full/path/to/repository

            
            </pre>


            <p>This makes your SSH program launch a private 'svnserve' process on

            
            the remote box, which accesses the repository as your UID and tunnels

            
            the information back over the encrypted link.</p>


            <p>However, another solution that can be used instead is to leverage

            
            SSH port forwarding to connect to the protected server via ra_dav.

            
            You would connect via SSH to a machine behind your firewall that can

            
            access your Subversion server.  Note that this SSH server does

            
            <b>not</b> have to be the same as where Subversion is installed.  It

            
            can be, but it doesn't have to be.</p>


            <p>Then, you create a local port forward that connects to the HTTP

            
            server that houses your Subversion repository.  You would then

            
            'connect' to the Subversion repository via this local port.  Then,

            
            the request will be sent 'tunneled' via SSH server to your Subversion

            
            server.</p>


            <p>An example: a Subversion ra_dav setup is behind your company firewall

            
            at 10.1.1.50 (call it svn-server.example.com).  Your company allows SSH

            
            access via publicly accessible ssh-server.example.com. Internally, you

            
            can access the Subversion repository via

            
            http://svn-server.example.com/repos/ours.</p>


            <p><i>Example</i>: client connecting to ssh-server with port-forwarding

            
            and checking out via the port forward</p>


            <pre>

            
            % ssh -L 8888:svn-server.example.com:80 me@ssh-server.example.com

            
            % svn checkout http://localhost:8888/repos/ours

            
            </pre>


            <p>Note that your svn-server.example.com could also have its httpd

            
            instance running on an unprivileged port by a non-trusted user.  This

            
            will allow your Subversion server not to require root access.</p>


            <!-- Can you use svn switch to switch your WC between your internal and

            
                 external Subversion server?  I think so.  -->


            <p>Joe Orton notes</p>

            
            <pre>

            
            The server is sensitive to the hostname used in the Destination header

            
            in MOVE and COPY requests, so you have to be a little careful here - a

            
            "ServerAlias localhost" may be required to get this working properly.

            
            </pre>


            <p>Some links on SSH port forwarding</p>


            </div>

            
            <ul>

            
            <li><a href="http://www.onlamp.com/pub/a/onlamp/excerpt/ssh_11/index3.html"

            
            >http://www.onlamp.com/pub/a/onlamp/excerpt/ssh_11/index3.html</a></li>

            
            <li><a href="http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/"

            
            >http://csociety.ecn.purdue.edu/~sigos/projects/ssh/forwarding/</a></li>

            
            <li><a href="http://www.zip.com.au/~roca/ttssh.html">TTSSH: A Win32 SSH client capable of port forwarding</a></li>

            
            </ul>


            <![CDATA[=========================================================]]>


            <div class="h3" id="multi-proj" title="multi-proj">

            
            <h3>How do I manage several different projects under Subversion?</h3>


            <p>It depends upon the projects involved.  If the projects are

            
            related, and are likely to share data, then it's best to create one

            
            repository with several subdirectories like this:</p>

            
            <pre>

            
            	$ svnadmin create /repo/svn

            
            	$ svn mkdir file:///repo/svn/projA

            
            	$ svn mkdir file:///repo/svn/projB

            
            	$ svn mkdir file:///repo/svn/projC

            
            </pre>


            <p>If the projects are completely unrelated, and not likely to share data

            
            between them, then it's probably best to create separate and unrelated

            
            repositories.</p>

            
            <pre>

            
            	$ mkdir /repo/svn

            
            	$ svnadmin create /repo/svn/projA

            
            	$ svnadmin create /repo/svn/projB

            
            	$ svnadmin create /repo/svn/projC

            
            </pre>

            
            <p>

            
            The difference between these two approaches is this (as explained by

            
            Ben Collins-Sussman &lt;sussman@collab.net&gt;):</p>


            </div>


            <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>


            <![CDATA[=========================================================]]>


            <div class="h3" id="multi-merge" title="multi-merge">

            
            <h3>How do I merge two completely separate repositories?</h3>


            <p>If you don't care about retaining all the history of one of the

            
            repositories, you can just create a new directory under one project's

            
            repository, then import the other.</p>


            <p>If you care about retaining the history of both, then you can use

            
            'svnadmin dump' to dump one repository, and 'svnadmin load' to load it into

            
            the other repository.  The revision numbers will be off, but you'll

            
            still have the history.</p>


            <p>Peter Davis &lt;peter@pdavis.cx&gt; also explains a method using svn's

            
            equivalent to CVS modules:</p>


            <blockquote>

            
            	<p>As long as the merging takes place in separate directory

            
            	trees, you can use svn's version of CVS modules.</p>


            	<p>Set the <em>svn:externals</em> property on a directory to checkout

            
            	directories from other repositories whenever the original

            
            	directory is checked out.  The repository remains separate,

            
            	but in the working copy it appears that they have been merged.

            
            	If you commit to the imported directory, it will affect the

            
            	external repository.</p>


            	<p>The merge isn't completely clean: the import only affects

            
            	working copies, so you won't be able to use a URL in the first

            
            	repository to access modules imported from the second.  They

            
            	remain separate URLs.</p>

            
            </blockquote>

            
            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="nfs" title="nfs">

            
            <h3>Should I store my repository / working copy on a NFS

            
            server?</h3>


            <p>If you are using a repository with the Berkeley DB back end

            
            (currently the default), do <i>not</i> access the repository via NFS.

            
            BDB <a href="http://www.sleepycat.com/docs/ref/env/remote.html">does

            
            not support storage of databases on remote file systems</a>.  Some NFS

            
            servers claim that they explicitly support use of BDB on NFS-mounted

            
            partitions, but we've only ever seen BDB databases get corrupted when

            
            living on an NFS or SMB network drive.</p>


            <p>If you are using the <a

            
            href="http://svn.collab.net/repos/svn/trunk/notes/fsfs">FSFS</a>

            
            repository back end, then storing the repository on a modern NFS

            
            server (i.e., one that supports locking) should be fine.</p>


            <p>Working copies can be stored on NFS (one common scenario is when

            
            your home directory is on a NFS server).  On Linux NFS servers, due to

            
            the volume of renames used internally in Subversion when checking out

            
            files, some users have reported that 'subtree checking' should be

            
            disabled (it's enabled by default).  Please see <a

            
            href="http://nfs.sourceforge.net/nfs-howto/server.html" >NFS Howto

            
            Server Guide</a> and <b>exports(5)</b> for more information on how to

            
            disable subtree checking.</p>


            <p>We've had at least one report of working copies getting wedged

            
            after being accessed via SMB.  The server in question was running a

            
            rather old version of Samba (2.2.7a).  The problem didn't recur with a

            
            newer Samba (3.0.6).</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="bdblogs" title="bdblogs">

            
            <h3>Why is my repository taking up so much disk space?</h3>


            <p>The repository stores all your data in a Berkeley DB "environment"

            
            in the repos/db/ subdirectory.  The environment contains a collection

            
            of tables and bunch of logfiles (log.*).  Berkeley DB journals all

            
            changes made to the tables, so that the tables can be recovered to a

            
            consistent state in case of interruptions (<a

            
            href="#wedged-repos">more info</a>).</p>


            <p>The logfiles will grow forever, eating up disk space, unless you,

            
            (as the repository administrator) do something about it.  At any given

            
            moment, Berkeley DB is only using a few logfiles actively (see <a

            
            href="http://subversion.tigris.org/servlets/ReadMsg?list=users&amp;msgNo=15194"

            
            >this post</a> and its associated thread); the rest can be safely

            
            deleted.  If you keep all the logfiles around forever, then in theory

            
            Berkeley DB can replay every change to your repository from the day it

            
            was born.  But in practice, if you're making backups, it's probably

            
            not worth the cost in disk space.</p>


            <p>Use <code>svnadmin</code> to see

            
            which log files can be deleted.  You may want a cron job to do this.</p>


            <pre>

            
            $ svnadmin list-unused-dblogs /repos

            
            /repos/db/log.000003

            
            /repos/db/log.000004

            
            [...]


            $ svnadmin list-unused-dblogs /repos | xargs rm

            
            # disk space reclaimed!

            
            </pre>


            <p>You could instead use Berkeley DB's <code>db_archive</code> command:</p>


            <pre>

            
            $ db_archive -a -h /repos/db | xargs rm

            
            # disk space reclaimed!

            
            </pre>


            <p>See also <code>svnadmin hotcopy</code> or <code>hotbackup.py</code>.</p>


            <p><strong>Note:</strong> If you use Berkeley DB 4.2, Subversion 0.35

            
            or later will create new repositories with automatic log file removal

            
            enabled. You can change this by passing the <code>--bdb-log-keep</code>

            
            option to <code>svnadmin create</code>. Refer to the section about the <a

            
            href="http://www.sleepycat.com/docs/api_c/env_set_flags.html#DB_LOG_AUTOREMOVE">

            
            <code>DB_LOG_AUTOREMOVE</code></a> flag in the Berkeley DB manual.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="reposperms" title="reposperms">

            
            <h3>How do I set repository

            
            permissions correctly?</h3>


            <p>Try to have as <em>few</em> users access the repository as

            
            possible.  For example, run apache or 'svnserve -d' as a specific

            
            user, and make the repository wholly owned by that user.  Don't allow

            
            any other users to access the repository via <tt>file:///</tt> urls,

            
            and be sure to run 'svnlook' and 'svnadmin' only as the user which

            
            owns the repository.</p>


            <p>If your clients are accessing via <tt>file:///</tt> or

            
            <tt>svn+ssh://</tt>, then there's no way to avoid access by multiple

            
            users.  In that case, read <a

            
            href="http://svnbook.red-bean.com/html-chunk/ch06s05.html">the last

            
            section in chapter 6</a>, and pay particular attention to the

            
            "checklist" sidebar at the bottom.  It outlines a number of steps to

            
            make this scenario safer.</p>


            <b>Note for SELinux / Fedora Core 3+ / RedHat 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>


            <![CDATA[=========================================================]]>


            <div class="h3" id="readonly" title="readonly">

            
            <h3>Why do read-only operations still need repository

            
            write access?</h3>


            <p>Certain client operations are "read-only", like checkouts and

            
            updates.  From an access-control standpoint, apache treats them as

            
            such.  But libsvn_fs (the repository filesystem API) still has to

            
            write temporary data in order to produce tree-deltas.  So the process

            
            accessing the repository always requires both read <em>and</em> write

            
            access to the Berkeley DB files in order to function.</p>


            <p>In particular, the repository responds to many "read-only"

            
            operations by comparing two trees.  One tree is the usually the HEAD

            
            revision, and the other is often a temporary transaction-tree -- thus

            
            the need for write access.</p>


            <p>This limitation only applies to the bdb backend; the <a

            
            href="http://svnbook.red-bean.com/svnbook-1.1/ch05.html#svn-ch-5-sect-1.2.A">FSFS

            
            backend</a> does not exhibit this behaviour.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="removal" title="removal">

            
            <h3>

            
            How do I completely remove a file from the repository's history?

            
            </h3>


            <p>There are special cases where you might want to destroy all

            
            evidence of a file or commit. (Perhaps somebody accidentally committed

            
            a confidential document.) This isn't so easy, because Subversion is

            
            deliberately designed to never lose information. Revisions are

            
            immutable trees which build upon one another. Removing a revision from

            
            history would cause a domino effect, creating chaos in all subsequent

            
            revisions and possibly invalidating all working copies.</p>


            <p>The project has plans, however, to someday implement an <b>svnadmin

            
            obliterate</b> command which would accomplish the task of permanently

            
            deleting information. (See <a

            
            href="http://subversion.tigris.org/issues/show_bug.cgi?id=516">issue

            
            516</a>.)</p>


            <p>In the meantime, your only recourse is to <b>svnadmin dump</b> your

            
            repository, then pipe the dumpfile through <b>svndumpfilter</b>

            
            (excluding the bad path) into an <b>svnadmin load</b> command.  See <a

            
            href="http://svnbook.red-bean.com/html-chunk/ch05.html">chapter 5</a>

            
            of the Subversion book for details about this.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="change-log-msg" title="change-log-msg">

            
            <h3>

            
            How do I change the log message for a revision after it's been committed?

            
            </h3>


            <p>Log messages are kept in the repository as properties attached to each

            
            revision.  By default, the log message property (<em>svn:log</em>) cannot be

            
            edited once it is committed.  That is because changes to <a

            
            href="http://svnbook.red-bean.com/svnbook/ch05.html#svn-ch-5-sect-1.2">revision

            
            properties</a> (of which <em>svn:log</em> is one) cause the property's

            
            previous value to be permanently discarded, and Subversion tries to prevent

            
            you from doing this accidentally.  However, there are a couple of ways to get

            
            Subversion to change a revision property.</p>


            <p>The first way is for the repository administrator to enable revision

            
            property modifications.  This is done by creating a hook called

            
            "pre-revprop-change" (see <a

            
            href="http://svnbook.red-bean.com/svnbook/ch05s02.html#svn-ch-5-sect-2.1">this

            
            section</a> in the Subversion book for more details about how to do this).

            
            The "pre-revprop-change" hook has access to the old log message before it is

            
            changed, so it can preserve it in some way (for example, by sending an email).

            
            Once revision property modifications are enabled, you can change a revision's

            
            log message by passing the --revprop switch to <b>svn propedit</b> or <b>svn

            
            propset</b>, like either one of these:</p>


            <pre>

            
            $ svn propedit -r N --revprop svn:log URL

            
            $ svn propset -r N --revprop svn:log "new log message" URL

            
            </pre>


            <p>where N is the revision number whose log message you wish to change, and

            
            URL is the location of the repository.  If you run this command from within a

            
            working copy, you can leave off the URL.</p>


            <p>The second way of changing a log message is to use <b>svnadmin setlog</b>.

            
            This must be done by referring to the repository's location on the filesystem.

            
            You cannot modify a remote repository using this command.</p>


            <pre>

            
            $ svnadmin setlog REPOS_PATH -r N FILE

            
            </pre>


            <p>where REPOS_PATH is the repository location, N is the revision number whose

            
            log message you wish to change, and FILE is a file containing the new log

            
            message.  If the "pre-revprop-change" hook is not in place (or you want to

            
            bypass the hook script for some reason), you can also use the --bypass-hooks

            
            option.  However, if you decide to use this option, be very careful.  You may

            
            be bypassing such things as email notifications of the change, or backup

            
            systems that keep track of revision properties.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="patch" title="patch">

            
            <h3>How do I submit a patch for Subversion?</h3>


            <p>FIRST, read the <a href="http://svn.collab.net/repos/svn/trunk/HACKING">HACKING</a> document.</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>


            </div>

            
            <blockquote><pre>

            
            	$ svn co http://svn.collab.net/repos/svn/trunk subversion

            
            	$ cd subversion/www


            		[ make changes to faq.html ]


            	$ svn diff faq.html &gt; /tmp/foo


            	$ Mail -s "[PATCH] FAQ updates" &lt; /tmp/foo

            
            </pre></blockquote>


            Of course, the email you send should contain a nice long

            
            explanation about what the patch does, as per the

            
            <a href="http://svn.collab.net/repos/svn/trunk/HACKING">HACKING</a>

            
            document, but you already know that, since you read and completely

            
            understood it <em>before</em> actually hacking the code, right? :)


            <![CDATA[=========================================================]]>


            <div class="h3" id="in-place-import" title="in-place-import">

            
            <h3>How can I do an in-place 'import'

            
                (i.e. add a tree to subversion such that the original data becomes

            
                a working copy directly)?</h3>


            <p>Suppose, for example, that you wanted to put some of /etc under

            
            version control inside your repository:</p>


            <pre>

            
                 # svn mkdir file:///root/svn-repository/etc \

            
                     -m "Make a directory in the repository to correspond to /etc"

            
                 # cd /etc

            
                 # svn checkout file:///root/svn-repository/etc .

            
                 # svn add apache samba alsa X11

            
                 # svn commit -m "Initial version of my config files"

            
            </pre>


            <p>This takes advantage of a not-immediately-obvious feature of

            
            <tt>svn&nbsp;checkout</tt>: you can check out a directory from the repository

            
            directly into an existing directory.  Here, we first make a new empty directory

            
            in the repository, and then check it out into <tt>/etc</tt>, transforming

            
            <tt>/etc</tt> into a working copy.  Once that is done, you can use normal

            
            <tt>svn&nbsp;add</tt> commands to select files and subtrees to add to the

            
            repository.</p>


            <p>There is an issue filed for enhancing <tt>svn&nbsp;import</tt> to

            
            be able to convert the imported tree to a working copy automatically;

            
            see <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1328"

            
            >issue 1328</a>.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="dumpload" title="dumpload">

            
            <h3>What is this "dump/load cycle" people

            
                sometimes talk about when upgrading a Subversion server?</h3>


            <p>Subversion's repository database schema has changed occasionally

            
            during development. Old repositories, created with a pre-1.0

            
            development version of Subversion, may require the following operation

            
            when upgrading.  If a schema change happens between Subversion

            
            releases X and Y, then repository administrators upgrading to Y must

            
            do the following: </p>


            <ol>

            
             <li>Shut down svnserve, Apache, and anything else that might be

            
                 accessing the repository.

            
             </li>


             <li>

            
             <b>

            
             <tt>svnadmin&nbsp;dump&nbsp;/path/to/repository&nbsp;>&nbsp;dumpfile.txt</tt>

            
             </b>,

            
               using version X of svnadmin.

            
             </li>


             <li>

            
             <b>

            
             <tt>mv&nbsp;/path/to/repository&nbsp;/path/to/saved-old-repository</tt>

            
             </b>

            
             </li>


             <li>Now upgrade to Subversion Y (i.e., build and install Y, replacing X).

            
             </li>


             <li>

            
             <b><tt>svnadmin&nbsp;create&nbsp;/path/to/repository</tt></b>, using version

            
               Y of svnadmin.

            
             </li>


             <li>

            
             <b>

            
             <tt>svnadmin&nbsp;load&nbsp;/path/to/repository&nbsp;&lt;&nbsp;dumpfile.txt</tt>

            
             </b>,

            
               again using version Y of svnadmin.

            
             </li>


             <li>Copy over hook scripts, etc, from the old repository to the new one.

            
             </li>


             <li>Restart svnserve, Apache, etc.

            
             </li>

            
            </ol>


            <p> See

            
            <a href="http://svnbook.red-bean.com/html-chunk/ch05s03.html#svn-ch-5-sect-3.4"

            
            >http://svnbook.red-bean.com/html-chunk/ch05s03.html#svn-ch-5-sect-3.4</a>

            
            for more details on dumping and loading.</p>


            <p> <b>Note</b>: Most upgrades of Subversion do <i>not</i> involve a

            
            dump and load.  When one is required, the release announcement and the

            
            CHANGES file for the new version will carry prominent notices about

            
            it.  If you don't see such a notice, then there has been no schema

            
            change, and no dump/load is necessary. </p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="sspi" title="sspi">

            
            <h3>How do I allow clients to authenticate against a

            
                Windows domain controller using SSPI authentication?</h3>


            <p><a href="http://tortoisesvn.tigris.org">TortoiseSVN</a> has an excellent

            
            document that describes setting up a Subversion server on Windows. Go to

            
            <a href="http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch03.html#tsvn-serversetup-apache-5"

            
            >http://tortoisesvn.tigris.org/docs/TortoiseSVN_en/ch03.html#tsvn-serversetup-apache-5</a>,

            
            to see the section on SSPI authentication.</p>


            <p>An earlier version of this document left out a line:</p>

            
            <pre>

            
               SSPIOfferBasic On

            
            </pre>


            <p>Without this line, a browser will prompt for the user's credentials,

            
            but Subversion clients will not. (The browser understands SSPI

            
            authentication, but 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>


            <![CDATA[=========================================================]]>


            <div class="h3" id="adm-dir" title="adm-dir">

            
            <h3>I don't like the ".svn" directory name, and

            
                prefer "SVN" or something else.  How do I change it?</h3>


            <p>We recommend that you live with ".svn" if you possibly can.  If you

            
            use some other name, your working copy may not work with Subversion

            
            clients other than the one you regularly use.  However, if you

            
            absolutely must, you can simply change this line in

            
            <tt>subversion/include/svn_wc.h</tt> from </p>


            <pre>

            
            #define SVN_WC_ADM_DIR_NAME   ".svn"

            
            </pre>


            <p>

            
            to

            
            </p>


            <pre>

            
            #define SVN_WC_ADM_DIR_NAME   "SVN"

            
            </pre>


            <p>

            
            then recompile your client.

            
            </p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="case-change" title="case-change">

            
            <h3>How do I change the case of a filename?</h3>


            <p>This problem comes up in two situations.  If you're adding files on

            
            an operating system with a case-insensitive filesystem, such as

            
            Windows, you might find you accidentally add a file with the wrong

            
            case in the filename.  Alternatively, you may just decide to change

            
            the case of an existing file in the repository.</p>


            <p>If you're working in a case-sensitive file system, this is no

            
            problem at all.  Just move the file to the new name, e.g.,</p>


            <pre>

            
            svn&nbsp;mv&nbsp;file.java&nbsp;File.java

            
            </pre>


            <p>But this won't work in a case-insensitive operating system like

            
            Windows.  In Windows you can accomplish this by copying the file

            
            somewhere temporary, deleting the file from Subversion, then adding

            
            the copy with the correct case.  Or a better way is to perform a move

            
            operation with Subversion URLs.  Using URLs is recommended, because it

            
            will preserve history for the file, and will take effect

            
            immediately.</p>


            <p>Both ways will leave Windows working copies with problems, however,

            
            because Windows can still get confused when trying to update the

            
            conflicting filenames.  (You'll get a message like <tt>svn: Failed to

            
            add file 'File.java': object of the same name already

            
            exists</tt>). One way of fixing the problem is to delete your working

            
            copy and check out again.  If you do not want to do this, you must

            
            perform a two step update.</p>


            <p>For each file with the wrong case, the following command will change

            
            the case:</p>


            <pre>

            
            svn mv svn://svnserver/path/to/file.java svn://svnserver/path/to/File.java

            
            </pre>


            <p>To update the working copy, change to the relevant directory and do:</p>


            <pre>

            
            svn update file.java

            
            svn update

            
            </pre>


            <p>The first update will remove <tt>file.java</tt> from your working

            
            copy, the second update will add <tt>File.java</tt>, leaving you with

            
            a correct working copy.  Or if you had a lot of problematic files, you

            
            can update the working copy this way:</p>


            <pre>

            
            svn update *

            
            svn update

            
            </pre>


            <p>As you can see, adding a file with the wrong case is tricky to fix on

            
            an operating system that has a case insensitive filesystem.  Do try to

            
            get it right when you add the file the first time!</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="merge-using-tags" title="merge-using-tags">

            
            <h3>I can't use tags to merge changes from a

            
                branch into the trunk like I used to with CVS, can I?</h3>


            <p>As shown below it is possible to merge from a branch to the trunk

            
            without remembering one revision number. Or vice versa (not shown in the

            
            example).</p>


            <p>The example below presumes an existing repository in <tt>/home/repos</tt>

            
            in which you want to start a branch named <tt>bar</tt> containing a file

            
            named <tt>foo</tt> you are going to edit.</p>


            <p>For the purpose of tracing branch merges, this repository has set up

            
            <tt>tags/branch_traces/</tt> to keep tags.</p>


            </div>


            <pre># setup branch and tags

            
            $ svn copy file:///home/repos/trunk \

            
                       file:///home/repos/branches/bar_branch \

            
                       -m "start of bar branch"

            
            $ svn copy file:///home/repos/branches/bar_branch \

            
                       file:///home/repos/tags/branch_traces/bar_last_merge \

            
                       -m "start"


            # checkout branch working copy

            
            $ svn checkout file:///home/repos/branches/bar_branch wc

            
            $ cd wc


            # edit foo.txt file and commit

            
            $ echo "some text" &gt;&gt;foo.txt

            
            $ svn commit -m "edited foo"


            # switch to trunk and merge changes from branch

            
            $ svn switch file:///home/repos/trunk

            
            $ svn merge file:///home/repos/tags/branch_traces/bar_last_merge \

            
                        file:///home/repos/branches/bar_branch


            # Now check the file content of 'foo.txt', it should contain the changes.


            # commit the merge

            
            $ svn commit -m "Merge change X from bar_branch."


            # finally, update the trace branch to reflect the new state of things

            
            $ svn delete -m "Remove old trace branch in preparation for refresh." \

            
                         file:///home/repos/tags/branch_traces/bar_last_merge

            
            $ svn copy file:///home/repos/branches/bar_branch                     \

            
                       file:///home/repos/tags/branch_traces/bar_last_merge       \

            
                       -m "Reflect merge of change X."

            
            </pre>


            <![CDATA[=========================================================]]>


            <div class="h3" id="version-value-in-source" title="version-value-in-source">

            
            <h3>Why doesn't the $Revision$

            
            keyword do what I want?  It expands to the file's last-changed revision,

            
            but I want something that will expand to the file's current revision.</h3>


            <p>

            
            Subversion increments the revision number of the repository as a

            
            whole, so it can't expand any keyword to be that number - it would

            
            have to search and possibly modify every file in your working copy on

            
            every update and commit.

            
            </p>


            <p>

            
            The information you want (the revision of your working copy) is

            
            available from the command <tt>svnversion</tt>; it gives you

            
            information on the revision level of a working copy given a path (see

            
            <tt>svnversion --help</tt> for details).

            
            </p>


            <p>

            
            You can incorporate it into your build or release process to get the

            
            information you need into the source itself.  For example, in a build

            
            environment based on <tt>make</tt>, add something like this to your

            
            <tt>Makefile</tt>:</p>


            <pre>

            
            ##

            
            ## on every build, record the working copy revision string

            
            ##

            
            svn_version.c: FORCE

            
                echo -n 'const char* svn_version(void) { const char* SVN_Version = "' \

            
                                                   &gt; svn_version.c

            
                svnversion -n .                   &gt;&gt; svn_version.c

            
                echo '"; return SVN_Version; }'   &gt;&gt; svn_version.c


            </pre>


            <p>

            
            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.

            
            </p>


            <p>

            
            Windows users may want to use <tt>SubWCRev.exe</tt>, available from

            
            the <a

            
            href='http://tortoisesvn.tigris.org/download.html'>TortoiseSVN

            
            download page</a>; it replaces all <tt>$WCREV$</tt> tags in a given

            
            file with the current working copy revision.

            
            </p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="log-in-source" title="log-in-source">

            
            <h3>Does Subversion have a keyword which

            
            behaves like $Log$ in CVS?</h3>


            <p>No.  There is no equivalent for the $Log$ keyword in CVS.  If you

            
            want to retrieve a log for a specific file, you can run

            
            'svn log your-file-name' or 'svn log url-to-your-file'.

            
            From the mailing list some explanations why $Log$ is bad:</p>


            <pre>"$Log$ is a total horror the moment you start merging changes

            
            between branches. You're practically guaranteed to get conflicts there,

            
            which -- because of the nature of this keyword -- simply cannot be

            
            resolved automatically."</pre>


            <p>And:</p>


            <pre>Subversion log messages are mutable, they can be changed by setting

            
            the svn:log revision property. So the expansion of $Log:$ in any

            
            given file could be out of date. Update may well need to retrieve the

            
            appropriate log message for each occurrence of the $Log:$ keyword,

            
            even if the file that contained it was not otherwise updated.</pre>


            <p><i>I don't care about that.  I want to use it anyway.

            
            Will you implement it?</i></p>


            <p>No.  There are no plans to implement it ourselves or accept patches

            
            which implement this feature.  If you want to distribute your files

            
            with some kind of changelog included, you might be able to work

            
            around this limitation in your build system.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="ignore-commit" title="ignore-commit">

            
            <h3>I have a file in my project that every

            
            developer must change, but I don't want those local mods to ever be

            
            committed.  How can I make 'svn commit' ignore the file?</h3>


            <p>The answer is: don't put that file under version control.  Instead,

            
            put a <em>template</em> of the file under version control, something

            
            like "file.tmpl".</p>


            <p>Then, after the initial 'svn checkout', have your users (or your

            
            build system) do a normal OS copy of the template to the proper

            
            filename, and have users customize the copy.  The file is unversioned,

            
            so it will never be committed.  And if you wish, you can add the file

            
            to its parent directory's svn:ignore property, so it doesn't show up

            
            as '?'  in the 'svn status' command.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="ssh-auth-cache" title="ssh-auth-cache">

            
            <h3>When I access a repository using

            
            svn+ssh, my password is not cached in ~/.subversion/auth/.  How do

            
            I avoid having to type it so often?</h3>


            <p>ssh has its own passphrases and its own authentication-caching

            
            scheme.  Its auth caching is external to Subversion, and must be set

            
            up independently of Subversion.</p>


            <p>OpenSSH includes <b><tt>ssh-keygen</tt></b> to create the keys,

            
            <b><tt>ssh-agent</tt></b> to cache passphrases, and

            
            <b><tt>ssh-add</tt></b> to add passphrases to the agent's cache.  A

            
            popular script to simplify usage of <tt>ssh-agent</tt> is

            
            <b><tt>keychain</tt></b>.  On Windows, <b><tt>PuTTY</tt></b> is a

            
            popular alternative ssh client; see <b><tt>PuTTYgen</tt></b> to import

            
            OpenSSH keys and <b><tt>pageant</tt></b> to cache passphrases.</p>


            <p>Setting up <tt>ssh-agent</tt> is outside the scope of this

            
            document, but a <a

            
            href="http://www.google.com/search?hl=en&amp;lr=&amp;ie=UTF-8&amp;q=%22ssh-agent%22"

            
            >Google search for "ssh-agent"</a> will quickly get you answers.  Or

            
            if you're <i>really</i> impatient, try one of these:</p>


            </div>


            <pre>

            
               <a href="http://www.csua.berkeley.edu/ssh-howto.html"

            
                        >http://www.csua.berkeley.edu/ssh-howto.html</a>

            
               <a href="http://mah.everybody.org/docs/ssh"

            
                       >http://mah.everybody.org/docs/ssh</a>

            
               <a href="http://kimmo.suominen.com/docs/ssh/"

            
                       >http://kimmo.suominen.com/docs/ssh/</a>

            
            </pre>


            <![CDATA[=========================================================]]>


            <div class="h3" id="ssh-svnserve-location" title="ssh-svnserve-location">

            
            <h3>My

            
            <tt>svnserve</tt> binary is in a directory that isn't on my

            
            users' default <tt>PATH</tt>s, they use svn+ssh, and I can't figure

            
            out how to modify their <tt>PATH</tt> so that they can run <tt>svnserve</tt>.</h3>


                  <p>Note: this all assumes you're using OpenSSH.  There are other

            
                  ssh implementations out there, and presumably they will allow

            
                  you to do something similar, but we don't yet know the details.</p>


                  <p>You've tried fiddling with their various login files, like

            
                    <tt>.bash_profile</tt>, and nothing works!  That's because ssh

            
                    ignores those files when the subversion client invokes it.

            
                    But there's no need to modify <tt>PATH</tt>; instead, you can

            
                    directly give ssh the full name of the <tt>svnserve</tt> command.

            
                    Here's how to do it:</p>


                  <p>For each user who needs svn+ssh access, generate a new ssh

            
                    public-key pair which they will use <em>only</em> for

            
                    subversion&mdash;not for logging in normally.  Have them give

            
                    the keypair a distinctive name, like

            
                    <tt>~/.ssh/id_dsa.subversion</tt>.  Add the public part of the

            
                    key to their <tt>~/.ssh/authorized_keys</tt> file on the

            
                    server machine, after first inserting a bit of magic at the

            
                    beginning of the line before the word <tt>ssh-rsa</tt> or

            
                    <tt>ssh-dss</tt>, like this:</p>


                  <table border="1" cellspacing="2" cellpadding="2">

            
                    <tr><th>before</th></tr>

            
                    <tr><td><tt>ssh-dss&nbsp;AAAAB3Nblahblahblahblah</tt></td></tr>

            
                    <tr><th>after</th></tr>

            
                    <tr><td><tt>

            
                    command="/opt/subversion/bin/svnserve&nbsp;-t"&nbsp;ssh-dss&nbsp;AAAAB3Nblahblahblahblah

            
                    </tt></td></tr>

            
                  </table>


                  <p>Obviously, replace <tt>/opt/subversion/bin/svnserve</tt> with

            
                  whatever is appropriate for your system.  You also might want to

            
                  specify the full path to the subversion repository in the

            
                  command (by using the <tt>-r</tt> option), to save your users

            
                  some typing.</p>


                  <p>The <tt>command=</tt> magic causes sshd on the remote machine

            
                    to invoke <tt>svnserve</tt>, even if your user tries to run

            
                    some other command.  See the sshd(8) man page (section

            
                    <tt>AUTHORIZED_KEYS FILE FORMAT</tt>) for details.</p>


                  <p>Now when your users run the subversion client, make sure they

            
                  have an <tt>SVN_SSH</tt> environment variable that "points to"

            
                  the private half of their keypair, by doing something like this

            
                  (for the Bourne Again shell):</p>


            </div>

            
            <pre>

            
            SVN_SSH="ssh -i $HOME/.ssh/id_dsa.subversion"

            
            export SVN_SSH

            
            </pre>


            <![CDATA[=========================================================]]>


            <div class="h3" id="auto-props" title="auto-props">

            
            <h3>How can I set certain properties on

            
            everything in the repository?  Also, how can I make sure that every

            
            new file coming into the repository has these properties?</h3>


            <p>Subversion will not change a file's contents by default; you have

            
            to deliberately set the <tt>svn:eol-style</tt> or

            
            <tt>svn:keywords</tt> property on a file for that to happen.  That

            
            makes Subversion a lot safer than CVS's default behavior, but with

            
            that safety comes some inconvenience.</p>


            <p>Answering the first question: to set properties on all files

            
            already in the repository, you'll need to do it the hard way.  All you

            
            can do is run <tt>svn propset</tt> on every file (in a working copy),

            
            and then <tt>svn commit</tt>.  Scripting can probably help you with

            
            this.</p>


            <p>But what about future files?  Unfortunately, there's no server

            
            mechanism to automatically set properties on files being committed.

            
            This means that all of your users need to remember to set certain

            
            properties whenever they <tt>svn add</tt> a file.  Fortunately,

            
            there's a client-side tool to help with this.  Read about the <a

            
            href="http://svnbook.red-bean.com/svnbook-1.1/ch07s02.html#svn-ch-7-sect-2.4">

            
            auto-props</a> feature in the book.  You need to make sure all your

            
            users configure their clients' auto-props settings appropriately.</p>


            <p>You could write a pre-commit hook script to reject any commit which

            
            forgets to add properties to new files (see <a

            
            href="http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl"

            
            >http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/check-mime-type.pl</a>

            
            for example).  However, this approach may be overkill.  If somebody

            
            forgets to set <tt>svn:eol-style</tt>, for example, it will be noticed

            
            the minute somebody else opens the file on a different OS.  Once

            
            noticed, it's easy to fix: just set the property and commit.</p>


            <p>Note: many users have asked for a feature whereby the server

            
            automatically "broadcasts" run-time settings to clients, such as

            
            auto-props settings.  There's already a feature request filed for this

            
            (<a

            
            href="http://subversion.tigris.org/issues/show_bug.cgi?id=1974">issue

            
            1974</a>), though this feature is still being debated by developers,

            
            and isn't being worked on yet.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="divining-bdb-version" title="divining-bdb-version">

            
            <h3>How do I determine which version of

            
            Berkeley DB a repository is using?</h3>


            <p>If it's a live repository, then the easy answer is "Whatever version

            
            of BDB you have installed".  If, however, it is a repository from a

            
            backup, or some unknown source, and you have no idea which version of

            
            BDB it was made with, here's how you find out:</p>


            <p>Run some command to view the two 4-byte integers at offsets 12 and 16

            
            (decimal) in the highest-numbered db/log.* file in the repository.  Here

            
            is an example using GNU od: "<tt>od -j12 -N8 -tx4

            
              log.<i>&lt;number&gt;</i></tt>".  Here is an example using Mac OS X

            
            hexdump: "<tt>hexdump -s12 -n8 -x log.<i>&lt;number&gt;</i></tt>".  The

            
            first integer should be the magic number 0x00040988, which identifies

            
            the file as a BDB logfile.  The second number is the log format version

            
            - match it to a BDB program version

            
            using the table below:</p>


            </div>


            <table border="1" cellspacing="2" cellpadding="2">

            
              <tr><th>Log format version</th><th>BDB program 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>

            
            </table>


            <![CDATA[=========================================================]]>


            <div class="h3" id="website-auto-update" title="website-auto-update">

            
            <h3>I'm managing a website in my

            
            repository.  How can I make the live site automatically update after

            
            every commit?</h3>


            <p>This is done all the time, and is easily accomplished by adding a

            
            post-commit hook script to your repository.  Read about hook scripts

            
            in <a

            
            href="http://svnbook.red-bean.com/en/1.1/ch05s02.html#svn-ch-5-sect-2.1">Chapter

            
            5</a> of the book.  The basic idea is to make the "live site" just an

            
            ordinary working copy, and then have your post-commit hook script run

            
            'svn update' on it.</p>


            <p>In practice, there are a couple of things to watch out for.  The

            
            server program performing the commit (svnserve or apache) is the same

            
            program that will be running the post-commit hook script.  That means

            
            that this program must have proper permissions to update the working

            
            copy.  In other words, the working copy must be owned by the same user

            
            that svnserve or apache runs as -- or at least the working copy must

            
            have appropriate permissions set.</p>


            <p>If the server needs to update a working copy that it doesn't own

            
            (for example, user joe's ~/public_html/ area), one technique is create

            
            a +s binary program to run the update, since Unix won't allow scripts

            
            to run +s.  Compile a tiny C program:</p>


            <pre>

            
            #include &lt;stdlib.h&gt;

            
            int main(int argc, const char *argv[])

            
            {

            
              system("/usr/local/bin/svn update /home/joe/public_html/");

            
            }

            
            </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>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>


            </div>


            <pre>

            
            # Disallow browsing of Subversion working copy administrative dirs.

            
            &lt;DirectoryMatch "^/.*/\.svn/"&gt;

            
                Order deny,allow

            
                Deny from all

            
            &lt;/DirectoryMatch&gt;

            
            </pre>


            <![CDATA[=========================================================]]>


            <div class="h3" id="single-file-checkout" title="single-file-checkout">

            
            <h3>How do I check out a single file?</h3>


            <p>Subversion does not support checkout of a single file, it only

            
            supports checkout of directory structures.</p>


            <p>However, you can use 'svn cat' to export a single file.  This will

            
            retrieve the file's contents, it just won't create a versioned working

            
            copy.</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="wc-change-detection" title="wc-change-detection">

            
            <h3>How do I detect adds, deletes,

            
            copies and renames in a working copy after they've already

            
            happened?</h3>


            <p>You don't.  It's a bad idea to try.</p>


            <p>The basic design of the working copy has two rules: (1) edit files

            
            as you please, and (2) use a Subversion cilent 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>


            <![CDATA[=========================================================]]>


            <div class="h3" id="svnserve-win-service" title="svnserve-win-service">

            
            <h3>How do I run svnserve as a service

            
            on Windows?</h3>


            <p>The <tt>svnserve</tt> binary itself cannot be installed as a

            
            Windows service, but there are a number of &ldquo;service

            
            wrappers&rdquo; that can do the job; for example:</p>


            <ul>

            
            <li><a href="http://dark.clansoft.dk/~mbn/svnservice/">SVNService</a>

            
            is a free tool written by Magnus Norddahl</li>

            
            <li><a href="http://support.microsoft.com/kb/q137890/">SrvAny</a>

            
            is avaliable free of charge from Microsoft</li>

            
            </ul>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="bdb-fsfs-convert" title="bdb-fsfs-convert">

            
            <h3>How do I convert my repository from using BDB

            
            to FSFS or from FSFS to BDB?</h3>


            <p>There are two 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>

            
            </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>Rename <tt>/svn/myrepos</tt> to <tt>/svn/myreposbdb</tt> and then

            
              <tt>/svn/myreposfsfs</tt> to <tt>/svn/myrepos</tt> ensuring that the

            
              file permissions are the same as those  that the BDB version had.</li>

            
              <li>Restart the server.</li>

            
            </ol>


            <p>Once you are happy that all is well with your new repository delete the old

            
            one.</p>


            <p>To do the reverse and migrate from FSFS to BDB change the <tt>svnadmin

            
            create</tt> command to specify BDB.</p>


            </div>


            <div class="h3" id="binary-files" title="binary-files">

            
            <h3>How does Subversion handle binary files?</h3>


            <p>When you first add or import a file into Subversion, the file is

            
            examined to determine if it is a binary file.  Currently, Subversion

            
            just looks at the first 1024 bytes of the file; if any of the bytes

            
            are zero, or if more than 15% are not ASCII printing characters, then

            
            Subversion calls the file binary.  This heuristic might be improved in

            
            the future, however.</p>


            <p>If Subversion determines that the file is binary, the file receives

            
            an svn:mime-type property set to "application/octet-stream".  (You can

            
            always override this by using the <a

            
            href="http://svnbook.red-bean.com/svnbook-1.1/ch07s02.html#svn-ch-7-sect-2.4"

            
            >auto-props feature</a> or by setting the property manually with

            
            <tt>svn propset</tt>.)</p>


            <p>Subversion treats the following files as text:</p>


            <ul>

            
              <li>Files with no svn:mime-type</li>

            
              <li>Files with a svn:mime-type starting "text/"</li>

            
              <li>Files with a svn:mime-type equal to "image/x-xbitmap"</li>

            
              <li>Files with a svn:mime-type equal to "image/x-xpixmap"</li>

            
            </ul>


            <p>All other files are treated as binary, meaning that Subversion will:</p>


            <ul>

            
              <li>Not attempt to automatically merge received changes with local

            
                  changes during <tt>svn update</tt> or <tt>svn merge</tt></li>

            
              <li>Not show the differences as part of <tt>svn diff</tt></li>

            
              <li>Not show line-by-line attribution for <tt>svn blame</tt></li>

            
            </ul>


            <p>In all other respects, Subversion treats binary files the same as

            
            text files, e.g. if you set the svn:keywords or svn:eol-style

            
            properties, Subversion will perform keyword substitution or newline

            
            conversion on binary files.</p>


            <p>Note that whether or not a file is binary does not affect the

            
            amount of repository space used to store changes to that file, nor

            
            does it affect the amount of traffic between client and server.  For

            
            storage and transmission purposes, Subversion uses a diffing method

            
            that works equally well on binary and text files; this is completely

            
            unrelated to the diffing method used by the 'svn&nbsp;diff'

            
            command.</p>


            </div>


            <![CDATA[=========================================================]]>


            </div>


            <div class="h2" id="troubleshooting" title="troubleshooting">

            
            <h2>Troubleshooting:</h2>

            
            <p/>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="permissions" title="permissions">

            
            <h3>

            
                <a name="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></h3>


            <p>The BerkeleyDB 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="#wedged-repos">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>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="wedged-repos" title="wedged-repos">

            
            <h3>

            
                <a name="bdb-recovery">Every time I try to access my repository, the

            
            process just hangs. Is my repository corrupt?</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 journaling system, meaning that it logs

            
            everything it is about to do before it does so.  If your process is

            
            interrupted (Control-C, or segfault), then a lockfile is left behind,

            
            along with a logfile describing unfinished business.  Any other

            
            process that attempts to access the database will just hang, waiting

            
            for the lockfile to disappear.  To awaken your repository, you need to

            
            ask Berkeley DB to either finish the work, or rewind the database to a

            
            previous state that is known to be consistent.</p>


            <p><b><span style="color: red">WARNING:</span> you can seriously corrupt

            
            your repository if you run recover and another process accesses the

            
            repository.</b></p>


            <p>Make absolutely sure you disable all access to the repository before

            
            doing this (by shutting down Apache, removing executable permissions from

            
            'svn').  Make sure you run this command as the user that owns and manages

            
            the database, and not as root, else it will leave root-owned files in the

            
            db directory which cannot be opened by the non-root user that manages the

            
            database, which is typically either you or your Apache process.  Also be

            
            sure to have the correct umask set when you run recover, since failing to

            
            do so will lock out users that are in the group allowed to access the

            
            repository.</p>


            <p>

            
            Simply run:</p>


            <pre>

            
               svnadmin recover /path/to/repos

            
            </pre>


            <p>Once the command has completed, check the permissions in the

            
            <code>db</code> directory of the repository.</p>


            <p>Sometimes "svnadmin&nbsp;recover" doesn't work.  You may see it

            
            give errors like this:</p>


            <pre>

            
              Repository lock acquired.

            
              Please wait; recovering the repository may take some time...

            
              svnadmin: DB_RUNRECOVERY: Fatal error, run database recovery

            
              svnadmin: bdb: Recovery function for LSN 175 7066018 failed on backward pass

            
              svnadmin: bdb: PANIC: No such file or directory

            
              svnadmin: bdb: PANIC: fatal region error detected; run recovery

            
            </pre>


            <p>or like this:</p>


            <pre>

            
              Repository lock acquired.

            
              Please wait; recovering the repository may take some time...

            
              svn: DB_RUNRECOVERY: Fatal error, run database recovery

            
              svn: bdb: DB_ENV-&gt;log_flush: LSN of 115/802071 past current end-of-log

            
              of 115/731460

            
              svn: bdb: Database environment corrupt; the wrong log files may have

            
              been removed or incompatible database files imported from another

            
              environment

            
              [...]

            
              svn: bdb: changes: unable to flush page: 0

            
              svn: bdb: txn_checkpoint: failed to flush the buffer cache Invalid argument

            
              svn: bdb: PANIC: Invalid argument

            
              svn: bdb: PANIC: fatal region error detected; run recovery

            
              svn: bdb: PANIC: fatal region error detected; run recovery

            
              [...]

            
            </pre>


            <p>In that case, try Berkeley DB's native <b>db_recover</b> utility

            
            (see <a href="http://www.sleepycat.com/docs/utility/db_recover.html"

            
            >http://www.sleepycat.com/docs/utility/db_recover.html</a>).  It

            
            usually lives in a "bin/" subdirectory of the Berkeley 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 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>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="bdb-cannot-allocate-memory" title="bdb-cannot-allocate-memory">

            
            <h3>My repository keeps giving errors saying "Cannot allocate memory".

            
                 What should I do?</h3>


            <p>If you're using http:// access, "<b>Cannot allocate memory</b>"

            
            errors show up in the httpd error log and look something like

            
            this:</p>


            <blockquote>

            
            <pre>

            
            [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (20014)

            
            Error string not specified yet: Berkeley DB error while opening

            
            'strings' table for filesystem /usr/local/svn/repositories/svn/db:

            
            Cannot allocate memory

            
            [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]

            
            Could not fetch resource information.  [500, #0]

            
            [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227]

            
            Could not open the requested SVN filesystem  [500, #160029]

            
            [Wed Apr 07 04:26:10 2004] [error] [client 212.151.130.227] (17)

            
            File exists: Could not open the requested SVN filesystem  [500, #160029]

            
            </pre>

            
            </blockquote>


            <p>It usually means that a Berkeley DB repository has run out of

            
            database locks (this does not happen with FSFS repositories).  It

            
            shouldn't happen in the course of normal operations, but if it does,

            
            the solution is to run database recovery as described <a

            
            href="#wedged-repos">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>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="wedged-wc" title="wedged-wc">

            
            <h3>Every time I try to run a svn command, it says my

            
            working copy is locked. Is my working copy corrupt?</h3>


            <p>

            
            Your working copy is not corrupt, nor is your data lost.  Subversion's

            
            working copy is 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>


            </div>


            <pre>

            
            svn cleanup working-copy

            
            </pre>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="wc-out-of-date" title="wc-out-of-date">

            
            <h3>I'm trying to commit, but Subversion says my

            
            working copy is out of date?</h3>


            <p>Three kinds of situation that can cause this:</p>


            <ol>


            <li><p>Debris from a failed commit is littering your working copy.</p>


                <p>You may have had a commit that went sour between the time the

            
                new revision was added in the server and the time your client

            
                performed its post-commit admin tasks (including refreshing your

            
                local text-base copy).  This might happen for various reasons

            
                including (rarely) problems in the database back end or (more

            
                commonly) network dropouts at exactly the wrong time.</p>


                <p>If this happens, it's possible that you have already committed

            
                the very changes you are trying now to commit.  You can use 'svn

            
                log -rHEAD' to see if your supposed-failed commit actually

            
                succeeded.  If it did, run 'svn revert' to revert your local

            
                changes, then run 'svn update' to your own changes back from the

            
                server.  (Note that only 'svn update' brings your local copies

            
                up-to-date; revert doesn't do that.)</p>

            
            </li>


            <li><p>Mixed revisions.</p>


                 <p>When Subversion commits, the client only bumps the revision

            
                 numbers of the nodes the commit touches, not all nodes in the

            
                 working copy.  This means that in a single working copy, the

            
                 files and subdirectories might be at different revisions,

            
                 depending on when you last committed them.  In certain operations

            
                 (for example, directory property modifications), if the

            
                 repository has a more recent version of the node, the commit will

            
                 be rejected, to prevent data loss.  See <a

            
                 href="http://svnbook.red-bean.com/svnbook/ch02s03.html#svn-ch-2-sect-3.4">

            
                 The Limitations of Mixed Revisions</a> in the <a

            
                 href="http://svnbook.red-bean.com/">Version Control with

            
                 Subversion</a> for details.</p>


                 <p>You can fix the problem by running 'svn update' in the working

            
                 copy.</p>

            
            </li>


            <li><p>You might be genuinely out of date&nbsp;&mdash;&nbsp;that is,

            
                you're trying to commit a change to a file that has been changed

            
                by someone else since you last updated your copy of that file.

            
                Again, 'svn update' is the way to fix this.</p>

            
            </li>

            
            </ol>

            
            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="unrecognized-url-error" title="unrecognized-url-error">

            
            <h3>I just built the distribution binary,

            
            and when I try to check out Subversion, I get an error about an

            
            "Unrecognized URL scheme."  What's up with that?</h3>


            <p>Subversion uses a plugin system to allow access to repositories.

            
            Currently there are three of these plugins: ra_local allows access to

            
            a local repository, ra_dav which allows access to a repository via

            
            WebDAV, and ra_svn allows local or remote access via the svnserve

            
            server.  When you attempt to perform an operation in subversion, the

            
            program tries to dynamically load a plugin based on the URL scheme.  A

            
            `file://' URL will try to load ra_local, and an `http://' URL will try

            
            to load ra_dav.</p>


            <p>The error you are seeing means that the dynamic linker/loader can't find

            
            the plugins to load.  This normally happens when you build subversion with

            
            shared libraries, then attempt to run it without first running 'make

            
            install'.  Another possible cause is that you ran make install, but the

            
            libraries were installed in a location that the dynamic linker/loader

            
            doesn't recognize.  Under Linux, you can allow the linker/loader to find the

            
            libraries by adding the library directory to /etc/ld.so.conf and running

            
            ldconfig.  If you don't wish to do this, or you don't have root access, you

            
            can also specify the library directory in the LD_LIBRARY_PATH environment

            
            variable.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="db-recover" title="db-recover">

            
            <h3>I'm getting errors finding or opening a repository,

            
                but I know my repository URL is correct.  What's wrong?</h3>


            <p>See <a href="#wedged-repos">this faq.</a></p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="configure-sed-error" title="configure-sed-error">

            
            <h3>When I run `<tt>configure</tt>', I get errors about

            
            <tt>subs-1.sed&nbsp;line&nbsp;38:&nbsp;Unterminated&nbsp;`s'&nbsp;command</tt>.

            
            What's wrong?</h3>


            <p>

            
            You probably have old copies of

            
            <tt>/usr/local/bin/apr-config</tt> and

            
            <tt>/usr/local/bin/apu-config</tt> on your system.  Remove them, make

            
            sure the <tt>apr/</tt> and <tt>apr-util/</tt> that you're

            
            building with are completely up-to-date, and try again.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="linux-bdb42-build" title="linux-bdb42-build">

            
            <h3>I'm having trouble building

            
                Subversion under *NIX with BerkeleyDB 4.2.x What should I do?</h3>


            <p>Subversion compiles against BerkeleyDB by asking apr-util for the

            
            appropriate BDB build options.  This means that either the apr-util in

            
            your Subversion tarball or the one in your Apache tree must

            
            successfully detect BDB.  Normally one does this by passing

            
            "--with-berkeley-db" to apr-util's ./configure.  (When you pass this

            
            argument to either Apache or Subversion's ./configure, it's really

            
            just getting passed down to apr-util's ./configure.)</p>


            <p>The problem is that BerkeleyDB 4.2 is newer than the latest

            
            released version of apr-util, so apr-util doesn't know how to detect

            
            it.</p>


            <p>The long-term solution is already in place: the latest apr-util in

            
            CVS has code to explicitly detect BDB 4.2.  When either apr-util or

            
            Apache httpd does another release, this ability will widely

            
            available.</p>


            <p>In the short term, the best thing to do is apply <a

            
            href="db42-support-patch.txt">this patch</a> to your apr-util's

            
            ./configure script -- either to the apr-util in your apache tree (if

            
            you're building Apache before Subversion), or to the apr-util in your

            
            Subversion tarball (if you're not building Apache at all.)  This patch

            
            is the new DB 4.2 detection code already in the latest apr-util

            
            CVS.</p>


            <p>If you've building Apache first, apply the patch to httpd-2.0.48's

            
            apr-util's configure script, and then build with these options:</p>


            <pre>

            
              $ configure \

            
              --enable-dav \

            
              --enable-so \

            
              --with-berkeley-db=/usr/local/BerkeleyDB.4.2 \

            
              --with-dbm=db42

            
            </pre>

            
            <p>

            
            You can confirm that Apache is built with the proper BDB libraries with the

            
            following command:

            
            </p>

            
            <pre>

            
              $ ldd /usr/local/apache2/bin/httpd | fgrep libdb

            
                  libdb-4.2.so =&gt; /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so

            
            </pre>


            <p>And then you can simply build Subversion with no mention of BDB.

            
            (...although Subversion <i>might</i> need to be told where to find

            
            your Apache installation, if it's in a non-standard place.)</p>


            <p>If you're not building Apache, apply the patch to the apr-util

            
             ./configure script in your Subversion tree, and use similar build

            
             options:</p>


            <pre>

            
              $ configure \

            
              --with-berkeley-db=/usr/local/BerkeleyDB.4.2 \

            
              --with-dbm=db42

            
            </pre>


            <p>

            
            Again, you can confirm that Subversion was built against the proper BDB

            
            library with the following:

            
            </p>

            
            <pre>

            
              $ ldd /usr/local/bin/svn | fgrep libdb

            
                  libdb-4.2.so =&gt; /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so

            
            </pre>


            <p>

            
            If you install your libraries in locations other than the defaults, you would

            
            need to adjust the paths at each step accordingly.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="windows-mod_dav_svn-build"

            
              title="windows-mod_dav_svn-build">

            
            <h3>I'm getting errors trying to build

            
                Subversion 1.2 on Windows &mdash; mod_dav_svn won't build.</h3>


            <p>It turns out that there's a small build-bug Apache httpd: not all

            
            of <tt>mod_dav</tt>'s public APIs were properly declared "exportable"

            
            on Windows.  And Subversion 1.2's <tt>mod_dav_svn</tt> is now using

            
            these APIs.  This means that out-of-the-box, Subversion 1.2 will not

            
            compile on Windows against any released httpd sourceball.</p>


            <p>This problem is already fixed on httpd's /trunk, and has been

            
            backported to the httpd 2.0.x branch.  If you're using a released

            
            httpd source tree, you're out of luck.  Until httpd-2.0.54 is

            
            released, you will need to manually apply <a

            
            href="httpd-win32.patch.txt">the same patch</a> to your httpd tree.

            
            (It's r155345 of httpd's trunk, for reference.)</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="windows-msvc-build" title="windows-msvc-build">

            
            <h3>I'm having trouble building Subversion

            
            under Windows with MSVC++ 6.0.  What should I do?</h3>


            <p>

            
            Probably you just need to get the latest platform SDK.  The one that

            
            ships with VC++ 6.0 is not recent enough.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="windows-drive-letter" title="windows-drive-letter">

            
            <h3>How can I specify a Windows drive letter in

            
            a <tt>file:</tt> URL?</h3>


            <p>Like this:</p>

            
            <pre>

            
            svn import file:///d:/some/path/to/repos/on/d/drive

            
            </pre>

            
            <p>See <a

            
            href="http://svnbook.red-bean.com/html-chunk/ch02s03.html#svn-ch-2-sidebar-1">

            
            Repository URLs</a> in the Subversion Book for more details.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="vs-asp-net" title="vs-asp-net">

            
            <h3>VS.NET/ASP.NET seems to have a problem with

            
                the ".svn" directory name.  What should I do?</h3>


            <p>VS.Net has a subsystem called ASP.Net, which uses WebDAV to do

            
            remote publishing through IIS.  This subsystem rejects any pathname

            
            that starts with ".".  This causes a problem when you try to remotely

            
            publish a Subversion working copy, because of the ".svn"

            
            subdirectories.  The error message says something like "unable to

            
            read project information".</p>


            <p>There are a few solutions:</p>


            <ul>

            
            <li><p>Recompile your client to use a different working copy name, as

            
                described <a href="#adm-dir">here</a>.  Or,</p>

            
            </li>

            
            <li><p>If you use TortoiseSVN, you can download a client that is

            
                already modified to work around the problem, see

            
                <a href="http://tortoisesvn.tigris.org/download.html"

            
                        >http://tortoisesvn.tigris.org/download.html</a>.  Or,</p>

            
            </li>

            
            <li><p>Take Jim Bolla's advice from

            
                <a href="http://weblogs.asp.net/fbouma/archive/2004/02/28/81479.aspx"

            
                        >http://weblogs.asp.net/fbouma/archive/2004/02/28/81479.aspx</a>:

            
                <i>"If you're working on web projects locally or across a file

            
                share, you can get around this by converting it to a regular class

            
                library project.  I have some docementation on how to do this that

            
                i've compiled from various sources on the internet about how to do

            
                this."</i> (We've contacted Jim Bolla about getting that

            
                documentation, and will include it here if we can.).  Or, </p>

            
            </li>

            
            <li><p>Steele Price, also on

            
                <a href="http://weblogs.asp.net/fbouma/archive/2004/02/28/81479.aspx"

            
                        >http://weblogs.asp.net/fbouma/archive/2004/02/28/81479.aspx</a>,

            
                says:

            
                <i>"You can get around the .SVN directory pretty easily by

            
                following instructions here: <a

            
                href="http://staff.develop.com/onion/Samples/aspdotnet_without_web_projects.htm">http://staff.develop.com/onion/Samples/aspdotnet_without_web_projects.htm</a>

            
                further instruction for making new projects is here:

            
                <a href="http://blog.steeleprice.net/archive/2003/11/09/134.aspx"

            
                        >http://blog.steeleprice.net/archive/2003/11/09/134.aspx</a>"

            
                </i></p>


            </li>

            
            </ul>

            
            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="write-over-dav" title="write-over-dav">

            
            <h3>I'm having trouble doing write

            
                operations to a Subversion repository over a network.</h3>


            <p>For example, one user reported that imports worked fine over local

            
            access:</p>

            
            <pre>

            
              $ mkdir test

            
              $ touch test/testfile

            
              $ svn import test file:///var/svn/test -m "Initial import"

            
              Adding         test/testfile

            
              Transmitting file data .

            
              Committed revision 1.

            
            </pre>

            
            But not from a remote host:

            
            <pre>

            
              $ svn import http://svn.sabi.net/test testfile -m "import"

            
              nicholas's password: xxxxxxx


              svn_error: #21110 : &lt;Activity not found&gt;


              The specified activity does not exist.

            
            </pre>


            <p> We've seen this when the REPOS/dav/ directory is not writable by

            
            the httpd process.  Check the permissions to ensure Apache can write

            
            to the <tt>dav/</tt> directory (and to <tt>db/</tt>, of course).  </p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="windows-xp-server" title="windows-xp-server">

            
            <h3>Under Windows XP, the Subversion server

            
                sometimes seems to send out corrupted data.  Can this really

            
                be happening?</h3>


            <p>You need to install Window XP Service Pack 1.  You can get all

            
            sorts of information about that Service Pack here:</p>


            </div>


                <ul><li>

            
                <a href="http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949"

            
                >http://support.microsoft.com/default.aspx?scid=kb;EN-US;q317949</a>

            
                </li></ul>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="ethereal" title="ethereal">

            
            <h3>What is the best method of doing a network

            
                trace of the conversation between a Subversion client and

            
                server?</h3>


            <p>Use <a href="http://ethereal.ntop.org/">Ethereal</a> to eavesdrop

            
            on the conversation:</p>


            <!-- TODO: Make these instructions less specific to ra_dav. -->

            
            <ol>

            
            <li>Pull down the <i>Capture</i> menu, and choose <i>Start</i>.</li>

            
            <li>Type <code>port 80</code> for <i>Filter</i>, and turn off

            
                promiscuous mode.</li>

            
            <li>Run your Subversion client.</li>

            
            <li>Hit <i>Stop</i> (probably in a little box).  Now you have a

            
                capture.  It looks like a huge list of lines.</li>

            
            <li>Click on the <i>Protocol</i> column to sort.</li>

            
            <li>Then, click on the first relevant TCP line to select it.</li>

            
            <li>Right click, and choose <i>Follow TCP Stream</i>.  You'll be

            
                presented with the request/response pairs of the Subversion

            
                client's HTTP conversion.</li>

            
            </ol>


            <p>The above instructions are specific to the graphical version of

            
            Ethereal, and may not apply to the commandline version (whose binary

            
            is usually named tethereal).</p>


            <p>Alternatively, if you have an up-to-date client (more recent than

            
            the 0.16 tarball) you may set the <tt>neon-debug-mask</tt> parameter in your

            
            <tt>servers</tt> configuration file to cause neon's debugging output

            
            to appear when you run the <tt>svn</tt> client.  The numeric value of

            
            <tt>neon-debug-mask</tt> is a combination of the <tt>NE_DBG_...</tt> values

            
            in the header file <tt>ne_utils.h</tt>.  For neon 0.23.7 setting

            
            <tt>neon-debug-mask</tt> to 130 (i.e. <tt>NE_DBG_HTTP+NE_DBG_HTTPBODY)</tt>

            
            will cause the HTTP data to be shown.</p>


            <p>You may well want to disable compression when doing a network

            
            trace, see the <tt>compression</tt> parameter in the <tt>config</tt>

            
            configuration file.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="revert" title="revert">

            
            <h3>Why does the <tt>svn revert</tt> require an

            
                explicit target?  Why is it not recursive by default?  These

            
                behaviors differ from almost all the other subcommands.</h3>


            <p>The short answer: it's for your own good.</p>


            <p>Subversion places a very high priority on protecting your data, and

            
            not just your versioned data.  Modifications that you make to

            
            already-versioned files, and new files scheduled for addition to the

            
            version control system, must be treated with care.</p>


            <p>Making the <tt>svn revert</tt> command require an explicit

            
            target&mdash;even if that target is just '.'&mdash;is one way of

            
            accomplishing that.  This requirement (as well as requiring you to

            
            supply the <tt>--recursive (-R)</tt> flag if you want that behavior)

            
            is intended to make you really think about what you're doing, because

            
            once your files are reverted, your local modifications are gone

            
            forever.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="db3db4" title="db3db4">

            
            <h3>When I start Apache, mod_dav_svn complains about

            
                a "bad database version", that it found db-3.X, rather than

            
                db-4.X.</h3>


            <p>Your apr-util linked against DB-3, and svn linked against DB-4.

            
            Unfortunately, the DB symbols aren't different.  When mod_dav_svn is

            
            loaded into Apache's process-space, it ends up resolving the

            
            symbol names against apr-util's DB-3 library.</p>


            <p>The solution is to make sure apr-util compiles against DB-4.  You

            
            can do this by passing specific switches to either apr-util's or

            
            apache's configure: "--with-dbm=db4 --with-berkeley-db=/the/db/prefix".</p>


            </div>


            <![CDATA[=========================================================]]>


            <div class="h3" id="redhat-db" title="redhat-db">

            
            <h3>I'm getting "Function not implemented" errors on RedHat

            
            9, and nothing works.  How do I fix this?</h3>


            <p>This is not really a problem with Subversion, but it often affects

            
            Subversion users.</p>


            <p>RedHat 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 RedHat 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 db4 for the kernel you're using.</li>

            
            <li>Use a RedHat 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 RedHat 9)</li>

            
            </ul>

            
            <p>To use the NPTL version of Berkeley DB you also need to use a glibc

            
            library with NPTL support, which probably means the i686 version. See

            
            <a

            
            href="http://svn.haxx.se/users/archive-2004-03/0488.shtml">

            
            http://svn.haxx.se/users/archive-2004-03/0488.shtml

            
            </a> for details.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="no-author" title="no-author">

            
            <h3>Why does SVN log say "(no author)" for files

            
                committed or imported via Apache (ra_dav)?</h3>


            <p>If you allow anonymous write access to the repository via Apache,

            
            the Apache server never challenges the SVN client for a username, and

            
            instead permits the write operation without authentication.  Since

            
            Subversion has no idea who did the operation, this results in a log

            
            like this:</p>


            <blockquote><pre>

            
            $ svn log

            
            ------------------------------------------------------------------------

            
            rev 24:&nbsp; (no author) | 2003-07-29 19:28:35 +0200 (Tue, 29 Jul 2003)

            
            </pre></blockquote>


            <p>See the Subversion Book (<a

            
            href="http://svnbook.red-bean.com/book.html#svn-ch-5-sect-4"

            
            >"Networking a Repository"</a>)

            
            to learn about configuring access restrictions in Apache.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="windows-access-denied" title="windows-access-denied">

            
            <h3>I'm getting occasional "Access Denied"

            
            errors on Windows.  They seem to happen at random.  Why?</h3>


            <p>These appear to be due to the various Windows services that monitor

            
            the filesystem for changes (anti-virus software, indexing services, the

            
            COM+ Event Notification Service).  This is not really a bug in Subversion,

            
            which makes it difficult for us to fix.  A summary of the current state of

            
            the investigation is available <a href=

            
            "http://svn.haxx.se/dev/archive-2003-10/0136.shtml">here</a>.

            
            A workaround that should reduce the incidence rate for most people was

            
            implemented in revision 7598; if you have an earlier version, please

            
            update to the latest release.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="freebsd-hang" title="freebsd-hang">

            
            <h3>On FreeBSD, certain operations (especially

            
                svnadmin create) sometimes hang.  Why?</h3>


            <p>This is usually due to a lack of available entropy on the system.

            
            You probably need to configure the system to gather entropy from

            
            sources such as hard-disk and network interrupts.  Consult your system

            
            manpages, specifically random(4) and rndcontrol(8) on how to effect

            
            this change.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <a name="301-error"></a> <!-- for compatibility with old

            
              non-XML-name-compliant fragment id -->

            
            <div class="h3" id="http-301-error" title="http-301-error">

            
            <h3>I can see my repository in a web browser, but

            
                'svn checkout' gives me an error about "301 Moved Permanently".

            
                What's wrong?</h3>


            <p>It means your httpd.conf is misconfigured.  Usually this error happens

            
            when you've defined the Subversion virtual "location" to exist within

            
            two different scopes at the same time.</p>


            <p>For example, if you've exported a repository as <tt>&lt;Location

            
            /www/foo&gt;</tt>, but you've also set your <tt>DocumentRoot</tt> to

            
            be <tt>/www</tt>, then you're in trouble.  When the request comes in

            
            for <tt>/www/foo/bar</tt>, apache doesn't know whether to find a

            
            <i>real</i> file named <tt>/foo/bar</tt> within your

            
            <tt>DocumentRoot</tt>, or whether to ask mod_dav_svn to fetch a file

            
            <tt>/bar</tt> from the <tt>/www/foo</tt> repository.  Usually the

            
            former case wins, and hence the "Moved Permanently" error.</p>


            <p>The solution is to make sure your repository

            
            <tt>&lt;Location&gt;</tt> does <b>not</b> overlap or live within any

            
            areas already exported as normal web shares.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="no-copy-history" title="no-copy-history">

            
            <h3>I'm trying to look at an old version of my

            
                file, but svn says something about "path not found".  What's going

            
                on?</h3>


            <p>A nice feature of Subversion is that the repository understands

            
            copies and renames, and preserves the historical connections.  For

            
            example, if you copy <tt>/trunk</tt> to <tt>/branches/mybranch</tt>,

            
            then the repository understands that every file in the branch has a

            
            "predecessor" in the trunk.  Running <tt>svn log --verbose</tt> will

            
            show you the historical copy, so you can see the rename:</p>


            <pre>

            
            r7932 | joe | 2003-12-03 17:54:02 -0600 (Wed, 03 Dec 2003) | 1 line

            
            Changed paths:

            
               A /branches/mybranch (from /trunk:7931)

            
            </pre>


            <p>Unfortunately, while the repository is aware of copies and renames,

            
            almost all the svn client subcommands are <b>not</b> aware.  Commands

            
            like <tt>svn diff</tt>, <tt>svn merge</tt>, and <tt>svn cat</tt> ought

            
            to understand and follow renames, but don't yet do this.  It's

            
            scheduled as post-1.0 feature, currently <a

            
            href="http://subversion.tigris.org/issues/show_bug.cgi?id=1093">issue

            
            #1093</a>.  For example, if you ask <tt>svn diff</tt> to compare two

            
            earlier versions of <tt>/branches/mybranch/foo.c</tt>, the command

            
            will not automatically understand that the task actually requires

            
            comparing two versions of <tt>/trunk/foo.c</tt>, due to the rename.

            
            Instead, you'll see an error about how the branch-path doesn't exist

            
            in the earlier revisions.</p>


            <p>The workaround for all problems of this sort is to do the legwork

            
            yourself.  That is: <i>you</i> need to be aware of any renamed paths,

            
            discover them yourself using <tt>svn log -v</tt>, and then provide

            
            them explicitly to the svn client.  For example, instead of

            
            running</p>


            </div>


            <pre>

            
            $ svn diff -r 1000:2000 http://host/repos/branches/mybranch/foo.c

            
            svn: Filesystem has no item

            
            svn: '/branches/mybranch/fooc..c' not found in the repository at revision 1000

            
            </pre>


            ...you would instead run


            <pre>

            
            $ svn diff -r1000:2000 http://host/repos/trunk/foo.c

            
            ...

            
            </pre>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="digest-auth" title="digest-auth">

            
            <h3>Why doesn't HTTP Digest auth work?</h3>


            <p>This is probably due to a known bug in Apache HTTP Server (versions

            
               2.0.48 and earlier), for which a patch is available, see

            
            <a href="http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040"

            
               >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25040</a>.  You

            
            may also want to read over

            
            <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=1608"

            
               >http://subversion.tigris.org/issues/show_bug.cgi?id=1608</a>

            
            to see if the description there matches your symptoms.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="xlc-compile" title="xlc-compile">

            
            <h3>Compiling with xlc on AIX, I get compilation

            
                errors.  What's wrong?</h3>


            <p>Adding <tt>-qlanglvl=extended</tt> to the

            
            environment variable CFLAGS for configuration and build

            
            will make xlc a bit more flexible and the code should

            
            compile without error.  See

            
            <a href="http://svn.haxx.se/dev/archive-2004-01/0922.shtml"

            
            >http://svn.haxx.se/dev/archive-2004-01/0922.shtml</a> and

            
            its associated thread for more details.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="nonrecursive-checkout" title="nonrecursive-checkout">

            
            <h3>I checked out a directory non-recursively

            
                (with -N), and now I want to make certain subdirectories

            
                "appear".  But <tt>svn up subdir</tt> doesn't work.</h3>


            <p>See <a

            
            href="http://subversion.tigris.org/issues/show_bug.cgi?id=695">issue

            
            695</a>.  The current implementation of <tt>svn checkout -N</tt> is

            
            quite broken.  It results in a working copy which has missing entries,

            
            yet is ignorant of its "incompleteness".  Apparently a whole bunch of

            
            CVS users are fairly dependent on this paradigm, but none of the

            
            Subversion developers were.  For now, there's really no workaround

            
            other than to change your process: try checking out separate

            
            subdirectories of the repository and manually nesting your working

            
            copies.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="mod_dav_svn-win32" title="mod_dav_svn-win32">

            
            <h3>I am trying to use mod_dav_svn

            
                with Apache on Win32 and I'm getting an error saying that the

            
                module cannot be found, yet the mod_dav_svn.so file is right

            
                there in <tt>\Apache\modules.</tt></h3>


            <p>The error message in this case is a little misleading. Most likely

            
            Apache is unable to load one or more DLLs that <tt>mod_dav_svn.so</tt>

            
            relies on.  If Apache is running as a service it will not have the

            
            same <tt>PATH</tt> as a regular user.  Make sure that

            
            <tt>libdb4*.dll</tt>, <tt>libeay32.dll</tt> and <tt>ssleay32.dll</tt>

            
            are present in either <tt>\Apache\bin</tt> or

            
            <tt>\Apache\modules</tt>.  You can copy them from your Subversion

            
            installation directory if they are not there.</p>


            <p>If this still does not resolve the problem, you should use a tool

            
            like <a href="http://www.dependencywalker.com">Dependency Walker</a>

            
            on <tt>mod_dav_svn.so</tt> to see if there are any other unresolved

            
            dependencies.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <a name="win32-hooks"></a> <!-- for compatibility with old question -->

            
            <a name="hook-environment"></a> <!-- for yet more compatibility with old question -->

            
            <div class="h3" id="hook-debugging" title="hook-debugging">

            
            <h3>Why aren't my repository hooks working?</h3>


            <p>They're supposed to invoke external programs, but the invocations

            
            never seem to happen.</p>


            <p>Before Subversion calls a hook script, it removes <em>all</em>

            
                        variables -- including $PATH on Unix, and %PATH% on Windows

            
                        -- from the environment.  Therefore, your script can only

            
                        run another program if you

            
            spell out that program's absolute name.</p>


            <p><b>Debugging tips:</b></p>

            
            <p>

            
            If you're using Linux or Unix, try running the script "by hand", by

            
            following these steps:</p>


            </div>

            
                      <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

            
                          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>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="diff-cmd" title="diff-cmd">

            
            <h3>Why does my --diff-cmd complain about '-u'?

            
                I tried to override it with --extensions, but it's not working.</h3>


            <p>When using an external diff command, subversion builds a fairly

            
            complicated command line. First is the specified --diff-cmd. Next comes

            
            the specified --extensions (although empty --extensions are ignored), or

            
            '-u' if --extensions is unspecified (or specified as ''). Third and

            
            fourth, Subversion passes a '-L' and the first file's label (e.g.

            
            "project_issues.html    (revision 11209)"). Fifth and sixth are another

            
            '-L' and the second label. Seventh and eighth are the first and second

            
            file names (e.g. ".svn/text-base/project_issues.html.svn-base" and

            
            ".svn/tmp/project_issues.html.tmp").</p>


            <p>If your preferred diff command does not support these arguments, you

            
            may need to create a small wrapper script to discard arguments and just

            
            use the last couple file paths.</p>


            <p>Warning: Beware that Subversion does not expect the external diff

            
            program to change the files it receives, and doing so may scramble the

            
            working copy.</p>


            <p>For further information, see issue

            
            <a href="http://subversion.tigris.org/issues/show_bug.cgi?id=2044">#2044</a>.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="plaintext-passwords" title="plaintext-passwords">

            
            <h3>Ahhh!  I just discovered that my

            
                Subversion client is caching passwords in plain-text on disk!

            
                AHHH!</h3>


            <p>Calm down, take a deep breath.</p>


            <p>First of all, notice that the directory which contains the cached

            
            passwords (usually ~/.subversion/auth/ on Unix systems) has permissions

            
            of 700, meaning only you can read them.  Trust your OS to protect data

            
            on disk.</p>


            <p>Secondly, if you're really worried, you can permanently turn off

            
            password caching.  With an svn 1.0 client, just set 'store-auth-creds

            
            = no' in your run-time config file.  With an svn 1.1 client or later,

            
            you can use the more narrowly-defined 'store-passwords = no' (so that

            
            server certs are still cached.)</p>


            <p>Lastly, we point out that CVS has been caching passwords for years

            
            in the .cvspass file.  It may look like the passwords in .cvspass are

            
            encrypted, but in fact they're only lightly scrambled with an

            
            algorithm that's the moral equivalent to rot13.  They can be cracked

            
            instantly.  The only utility of the the scrambling is to prevent users

            
            (like root) from accidentally seeing the password.  Nobody's cared

            
            enough to to do this for Subversion yet; if you're interested, send

            
            patches to the dev@ list.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="bdb41-tabletype-bug" title="bdb41-tabletype-bug">

            
            <h3>I'm getting the error "svn: bdb: call

            
                implies an access method which is inconsistent with previous

            
                calls". How do I fix this?</h3>


            <p>Berkeley DB 4.1 has shown itself to be rather unstable - both 4.0

            
            and 4.2 are better.  This error message is a symptom of one unique way

            
            in which 4.1 will sometimes break.</p>


            <p>The problem is that the database format field for one of the tables

            
            that make up a Subversion BDB-type repository has become corrupted.

            
            For unknown reasons, this is almost always the 'copies' table, which

            
            switches from the 'btree' type to the 'recno' type.  Simple recovery

            
            procedures are outlined below - if they do not succeed, you should

            
            contact the Subversion Users <a

            
              href="mailto:users@subversion.tigris.org">mailing list</a>.</p>


            </div>


            <ul>

            
              <li>Ensure that no other processes will attempt to access your

            
              repository.</li>

            
              <li>Now, <b>back up your repository</b> to a tar or zip file or

            
              similar.</li>

            
              <li>Change to the <tt>db</tt> subdirectory of your repository.</li>

            
              <li><tt>rm __db.* log.*</tt></li>

            
              <li><tt>db_dump -p -r copies &gt; copies.dump</tt></li>

            
              <li>Now edit <tt>copies.dump</tt>.  In the section near the top,

            
              change "<tt>type=recno</tt>" to "<tt>type=btree</tt>", and delete

            
              the line beginning "<tt>re_len=</tt>".</li>

            
              <li><tt>rm copies</tt></li>

            
              <li><tt>db_load copies &lt; copies.dump</tt></li>

            
              <li><tt>svnadmin dump .. &gt; ../../my-recovered.svndump</tt></li>

            
              <li>Now create a new repository, reload the dump file just produced,

            
              and copy across any custom hooks or configuration.  Verify that the

            
              highest revision number in the new repository is what you think it

            
              should be.</li>

            
            </ul>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="hotcopy-large-repos" title="hotcopy-large-repos">

            
            <h3>I can't hotbackup my repository,

            
                svnadmin fails on files larger than 2Gb!</h3>


            <p>Early versions of APR on its 0.9 branch, which Apache 2.0.x and

            
            Subversion 1.x use, have no support for copying large files (2Gb+).

            
            A fix which solves the 'svnadmin hotcopy' problem has been applied and

            
            is included in APR 0.9.5+ and Apache 2.0.50+.  The fix doesn't work

            
            on all platforms, but works on Linux.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="hidden-log" title="hidden-log">

            
            <h3>I cannot see the log entry for the file

            
                I just committed.  Why?</h3>


            <p>Assume you run '<tt>svn&nbsp;checkout</tt>' on a repository and

            
            receive a working copy at revision 7 (aka, r7) with one file in it

            
            called <tt>foo.c</tt>.  You modify the file and commit it

            
            successfully.  Two things happen:</p>


            <ul>

            
            <li>The repository moves to r8 on the server.</li>

            
            <li>In your working copy, only the file <tt>foo.c</tt> moves to r8.

            
                The rest of your working copy remains at r7.</li>

            
            </ul>


            <p>You now have what is known as a <i>mixed revision working copy</i>.

            
            One file is at r8, but all other files remain at r7 until they too are

            
            committed, or until '<tt>svn&nbsp;update</tt>' is run.</p>


            <pre>   $ svn -v status

            
               7        7 nesscg       .

            
               8        8 nesscg       foo.c

            
               $</pre>


            <p>If you run the '<tt>svn&nbsp;log</tt>' command without any

            
            arguments, it prints the log information for the current directory

            
            (named '<tt>.</tt>' in the above listing).  Since the directory itself

            
            is still at r7, you do not see the log information for r8.</p>


            <p>To see the latest logs, do one of the following:</p>


            <ol>

            
            <li>Run '<tt>svn&nbsp;log&nbsp;-rHEAD</tt>'.</li>

            
            <li>Run '<tt>svn&nbsp;log&nbsp;URL</tt>', where URL is the repository URL.</li>

            
            <li>Ask for just that file's log information, by running

            
                '<tt>svn&nbsp;log&nbsp;foo.c</tt>'.</li>

            
            <li>Update your working copy so it's all at r8, then run

            
                '<tt>svn&nbsp;log</tt>'.</li>

            
            </ol>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="bdb43-upgrade" title="bdb43-upgrade">

            
            <h3>After upgrading to Berkeley DB

            
                4.3, I'm seeing repository errors.</h3>


            <p>Normally one can simply run <tt>svnadmin recover</tt> to upgrade a

            
              Berkeley DB repository in-place.  However, due to a bug in the way

            
              this command invokes the <tt>db_recover()</tt> API, this won't work

            
              correctly when upgrading from BDB 4.0/4.1/4.2 to BDB 4.3.</p>


            <p>Use this procedure to upgrade your repository in-place to BDB 4.3:</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 BerkeleyDB):


              <ol>


              <li>Recover the

            
                repository: '<tt>svnadmin&nbsp;recover&nbsp;/path/to/repository</tt>'</li>


              <li>Make a backup of the repository.</li>


              <li>Delete all unused log files.  You can see them by running

            
                '<tt>svnadmin&nbsp;list-unused-dblogs&nbsp;/path/to/repeository</tt>'</li>


              <li>Delete the shared-memory files.  These are files in the

            
                  repository's <tt>db/</tt> directory, of the form <tt>__db.00*</tt></li>


              </ol>

            
            </li>


            </ul>


            <p>The repository is now usable by Berkeley DB 4.3.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="tiger-apr-0.9.6" title="tiger-apr-0.9.6">

            
            <h3>Why do I get occasional, seemingly inconsistent errors checking

            
                out over http:// from a repository running on MacOS X 10.4 (Tiger)?</h3>


            <p>Note: this assumes the repository is being served by Apache 2.0.x.</p>


            <p>There is a bug in APR 0.9.6 that is present when it is running on

            
            Tiger, and shows up when you attempt to check out a file larger than

            
            64K.  The resulting checkout fails, often with unpredictable error

            
            messages.  Here are some examples of what you might see on the client

            
            side, the specific errors may differ for you:</p>


            <pre>

            
               svn: Invalid diff stream: [tgt] insn 1 starts beyond the target view position

            
            </pre>


            <pre>

            
               svn: Unexpected end of svndiff input

            
            </pre>


            <pre>

            
               svn: REPORT request failed on '/path/to/repository'

            
               svn: REPORT of '/path/to/repository/!svn/vcc/default': Chunk delimiter was invalid

            
            </pre>


            <p>There may also be errors in the Apache error_log, such as:</p>


            <pre>

            
               [error] Provider encountered an error while streaming a REPORT response.  [500, #0]

            
               [error] A failure occurred while driving the update report editor [500, #190004]

            
            </pre>


            <p>To confirm the presence of this bug &nbsp;&mdash;&nbsp; assuming

            
            you have access to the machine that the repository is being served

            
            from &nbsp;&mdash;&nbsp; try checking out using a file:// URL, which

            
            will access the filesystem directly instead of going through Apache.

            
            If the resulting checkout completes successfully, then it is almost

            
            certain that this is the problem.</p>


            <p>Currently, the best solution is to 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>


            <![CDATA[=========================================================]]>


            </div>


            <div class="h2" id="developer-questions" title="developer-questions">

            
            <h2>Developer questions:</h2>

            
            <p/>


            <div class="h3" id="ramdisk-tests" title="ramdisk-tests">

            
            <h3>How do I run the regression tests in a

            
                RAM disk?</h3>


            <p>Test execution can be dramatically sped up by keeping Subversion

            
            test data on a RAM disk.  On a Linux system, add lines like the

            
            following in your /etc/fstab file:</p>


            <blockquote>

            
            <div><code>tmpfs  /home/brane/svn/obj-sh/subversion/tests  tmpfs  defaults,user,noauto,exec,size=64m</code></div>

            
            <div><code>tmpfs  /home/brane/svn/obj-st/subversion/tests  tmpfs  defaults,user,noauto,exec,size=64m</code></div>

            
            </blockquote>


            <p>The minimum required size for testing ramdisk is approximately 700MB.

            
            However, flagging your test targets for cleanup dramatically reduces

            
            the space requirements (as shown in the example configuration above),

            
            and thus your memory usage.  Cleanup means more I/O, but since test

            
            data is in-memory, there will be no performance degradation.  Example:</p>


            <blockquote><div><code>

            
            make check CLEANUP=true

            
            </code></div></blockquote>


            <p>See <a href="http://svn.haxx.se/dev/archive-2003-02/0068.shtml"

            
            >http://svn.haxx.se/dev/archive-2003-02/0068.shtml</a> for the

            
            original authoritative discussion on use of RAM disks.</p>


            </div>


            <![CDATA[=========================================================]]>


            </div>


            <div class="h2" id="references" title="references">

            
            <h2>References:</h2>

            
            <p/>


            <div class="h3" id="http-methods" title="http-methods">

            
            <h3>What are all the HTTP methods Subversion

            
                uses?</h3>


            <p>The following email says it all.  As the author points out,

            
            Subversion does not actually use all of these WebDAV/DeltaV methods

            
            yet, but it probably will someday, so if you're configuring a proxy,

            
            you might as well allow all of them:</p>


            <blockquote>

            
            <pre>

            
            From: Nuutti Kotivuori &lt;naked@iki.fi&gt;

            
            Subject: Re: list of HTTP messages used by svn?

            
            To: "Hamilton Link" &lt;helink@sandia.gov&gt;

            
            Cc: dev@subversion.tigris.org

            
            Date: Sat, 10 Aug 2002 13:51:52 +0300


            Hamilton Link wrote:

            
            &gt; Is there a full list of the HTTP methods svn uses somewhere, that

            
            &gt; someone could piont me to? From the documentation I can find (in

            
            &gt; particular project_faq.html and INSTALL), the list of methods svn

            
            &gt; uses include at least the following:

            
            &gt;

            
            &gt; GET, PROPFIND, REPORT, OPTIONS, MERGE, MKACTIVITY, and CHECKOUT

            
            &gt;

            
            &gt; But since the lists I can find are only partial lists and nowhere

            
            &gt; does it suggest these are all the ones used, I'm reluctant to make

            
            &gt; any assumptions.

            
            &gt;

            
            &gt; If I had a complete list, I could go to the corp. proxy guy once

            
            &gt; instead of many times, and reduce the risk of pissing him off and

            
            &gt; being left with inadequate svn support in the proxy.


            <a href="http://www.webdav.org/deltav/WWW10/deltav-intro.htm">http://www.webdav.org/deltav/WWW10/deltav-intro.htm</a>


            A list copied from there:


            HTTP/1.1: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, CONNECT


            WebDAV: LOCK, UNLOCK, PROPFIND, PROPPATCH, COPY, MOVE, MKCOL


            DeltaV: CHECKIN, CHECKOUT, UNCHECKOUT, VERSION-CONTROL, REPORT,

            
            UPDATE, LABEL, MERGE, MKWORKSPACE, BASELINE-CONTROL, MKACTIVITY


            Subversion uses no methods outside these. It doesn't use all of them

            
            either, but it's better to support the full WebDAV/DeltaV than just

            
            some arbitrary subset. If the proxy being configured is a recent

            
            Squid, it probably has everything from HTTP/1.1 and WebDAV - and then

            
            it only needs the DeltaV extensions added.


            You can give that list to your corp. proxy guy and explain to him that

            
            he can check the RFC's for further information.

            
            </pre>

            
            </blockquote>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="bikeshed" title="bikeshed">

            
            <h3>What's a 'bikeshed'?</h3>


            <p>See Poul-Henning Kamp's post to freebsd-hackers: <a href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING">http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING</a>.

            
            </p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="baton" title="baton">

            
            <h3>What's a 'baton'?</h3>


            <p>Throughout subversion's source code there are many references to

            
            'baton' objects.  These are just <tt>void *</tt> datastructures that

            
            provide context to a function.  In other APIs, they're often called

            
            <tt>void *ctx</tt> or <tt>void *userdata</tt>  Subversion

            
            developers call the structures "batons" because they're passed around

            
            quite a bit.</p>


            </div>


            <![CDATA[-----------------------------------------------------------]]>


            <div class="h3" id="def-wedged-repository" title="def-wedged-repository">

            
            <h3>What do you mean when you say that

            
                repository is 'wedged'?</h3>


            wedged repository:

            
            <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>


            corrupted repository:


            <blockquote>

            
            <p>A corrupted Subversion repository is a repository where the storage

            
            compartment has been damaged, and therefore there is some degree of

            
            real data loss in the repository.</p>

            
            </blockquote>


            <p>You might also like to check The Jargon File's definition for

            
            <a href="http://catb.org/~esr/jargon/html/W/wedged.html">'wedged'</a>.

            
            </p>


            </div>


            </div>


            </div>

            
            </body>

            
            </html>