Error running context an error occurred during ssl communication

Note that there is no need to escape the quotes in the Windows shell as they are not part of the syntax for the set command.

On UNIX systems you would need to follow your shell’s specific methods for setting the variable. For example, in a bash shell, the following should work:

In case a command line option would be needed for the invocation of the editor, just add that after the editor name in the SVN_EDITOR environment variable just like you would use on the command line. For example, if the options -nx -r would be wanted for the above editors, the following will provide those options:

Note that SVN_EDITOR is the Subversion specific environment variable setting for the editor selection. Subversion also supports using the more generic EDITOR variable but if you need special behaviors with Subversion it is best to use the SVN_EDITOR variable.

I’m managing a website in my repository. How can I make the live site automatically update after every commit? ¶

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 Chapter 5 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.

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.

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:

. and then chmod +s the binary, and make sure it’s owned by user ‘joe’. Then in the post-commit hook, add a line to run the binary.

If you have problems getting the hook to work, see «Why aren’t my repository hooks working?».

Also, you’ll probably want to prevent apache from exporting the .svn/ directories in the live working copy. Add this to your httpd.conf:

Finally, if the working copy to be updated isn’t on the same machine as the Subversion server, svnpubsub can be used on the Subversion server to advertise the commit to a listening svnwcsub client on the Web server.

How do I check out a single file? ¶

Subversion does not support checkout of a single file, it only supports checkout of directory structures.

However, you can use ‘svn export’ to export a single file. This will retrieve the file’s contents, it just won’t create a versioned working copy.

How do I detect adds, deletes, copies and renames in a working copy after they’ve already happened? ¶

You don’t. It’s a bad idea to try.

The basic design of the working copy has two rules: (1) edit files as you please, and (2) use a Subversion client to make any tree-changes (add, delete, move, copy). If these rules are followed, the client can sucessfully manage the working copy. If renames or other rearrangements happen outside of Subversion, then the UI has been violated and the working copy might be broken. The client cannot guess what happened.

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.

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.

How do I run svnserve as a service on Windows? ¶

For versions 1.4.0 and later, you can find instructions here.

How do I convert my repository from using BDB to FSFS or from FSFS to BDB? ¶

There are three steps:

1. A dump/load from the old format to the new one.
2. Copy the hook scripts.
3. Copy the configuration files.

Say you have a repository /svn/myrepos which is using the BDB backend and you would like to switch to using the FSFS backend:

1. Close down your server so that the data cannot change during this procedure.
2. Make a new repository specifying the fsfs backend (it is the default from 1.2 onwards), e.g., svnadmin create /svn/myreposfsfs —fs-type fsfs.
3. Pipe the output of a dump from /svn/myrepos to the input of a load into /svn/myreposfsfs, e.g., svnadmin dump /svn/myrepos -q | svnadmin load /svn/myreposfsfs. Windows users should dump to a file and load from that file in two separate steps.
4. Copy any hook scripts which are active in /svn/myrepos/hooks into /svn/myreposfsfs/hooks. Don’t mindlessly copy everything, the templates generated by Subversion may have changed.
5. Compare the template scripts which the svnadmin create command put in /svn/myreposfsfs/hooks with those in /svn/myrepos/hooks and incorporate any changes which you would like into your active hook scripts.
6. Copy configuration files from /svn/myrepos/conf into /svn/myreposfsfs/conf (and don’t forget a password file, if you use one). Or you might instead want to merge the changes that you made to your configuration files into the new default ones.
7. Rename /svn/myrepos to /svn/myreposbdb and then /svn/myreposfsfs to /svn/myrepos ensuring that the file permissions are the same as those that the BDB version had.
8. Restart the server.

Once you are happy that all is well with your new repository delete the old one.

To do the reverse and migrate from FSFS to BDB change the svnadmin create command to specify BDB.

How does Subversion handle binary files? ¶

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.

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 auto-props feature or by setting the property manually with svn propset.)

Subversion 1.7 and later can optionally be compiled with support for libmagic to detect MIME types of binary files which are added to version control. This feature is used only for binary files for which no MIME type is found via auto-props or the mime-types-file configuration option. If libmagic identifies a file as a text file, Subversion will treat the file as a text file by default.

Subversion treats the following files as text:

• Files with no svn:mime-type
• Files with a svn:mime-type starting «text/»
• Files with a svn:mime-type equal to «image/x-xbitmap»
• Files with a svn:mime-type equal to «image/x-xpixmap»

All other files are treated as binary, meaning that Subversion will:

• Not attempt to automatically merge received changes with local changes during svn update or svn merge
• Not show the differences as part of svn diff
• Not show line-by-line attribution for svn blame

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.

Note that whether or not a file is binary does not affect the amount of repository space used to store changes to that file, nor does it affect the amount of traffic between client and server. For storage and transmission purposes, Subversion uses a diffing method that works equally well on binary and text files; this is completely unrelated to the diffing method used by the ‘svn diff’ command.

How can I make svn diff show me just the names of the changed files, not their contents? ¶

svn diff doesn’t have an option to do this, but

• If you only are interested in the diffs between, say, revision 10 and the revision just before it, does exactly what you want;
• otherwise, if you’re using Unix, this works for any range of revisions:

Version 1.4 of the svn diff command will have a «—summarize» option.

How can I use wildcards or globbing to move many files at once? ¶

You want to do something like

but it fails with

. or some other inscrutable error message.

Subversion doesn’t expand wildcards like «*» in URL arguments. (Technically speaking, Subversion does not expand wildcards in local paths either, but on most operating systems the shell expands wildcards in local paths in the command line before passing the resulting list to Subversion.)

You have to generate the list of source URLs yourself. You could do it like this (in Bash):

In Subversion v1.4 and earlier, Subversion did not allow you to «cp» and «mv» multiple paths or URLs in one command. You have to issue multiple commands. If you happen to have a working copy that contains all the source files as well as the destination directory, then you can exploit your shell’s wildcard feature to do the move, like this (for Bash):

In any case, you can always accumulate a list of the names of the source files, and then run «svn mv» on each item in that list, like this:

Note, however, that this will generate one commit per source file; that’s in contrast to the above method (using a working copy) which generates just one commit total.

There is a program called «svnmucc» (previously «mucc»), whose source is distributed with Subversion, that enables you to combine multiple commands into one commit. See the Tools and Contrib page.

How can I maintain a modified version (a «vendor branch») of third-party software using Subversion? ¶

People frequently want to use Subversion to track their local changes to third-party code, even across upgrades from the third-party — that is, they want to maintain their own divergent branch, while still incorporating new releases from the upstream source. This is commonly called a vendor branch (the term long predates Subversion), and the techniques for maintaining one in Subversion are described here.

If the vendor code is hosted in a remote Subversion repository, then you can use Piston to manage your copy of the vendor’s code.

As a last resort, if using svn_load_dirs.pl is taking too much time or you’re looking for the lazy solution, see also Jon Stevens’ step-by-step explanation at Subversion Vendor Branches Howto. This solution does not make use of the space saving features in the Subversion backend when you copy new code over old code; in this solution, each import of a vendor code gets an entire new copy and there is no space savings for identical files.

How do I make the contents of a previous revision become HEAD again? ¶

Troubleshooting: ¶

Every time I try to run a svn command, it says my working copy is locked. Is my working copy corrupt? ¶

Your working copy is not corrupt, nor is your data lost. Subversion’s working copy is a journaling system, meaning that it logs everything it is about to do before it does so. If the svn client program is interrupted violently (segfault or killed, not with Control-C), then one or more lockfiles are left behind, along with logfiles describing unfinished business. (The `svn status’ command will show an ‘L’ next to locked directories.) Any other process that attempts to access the working copy will fail when it sees the locks. To awaken your working copy, you need to tell the svn client to finish the work. Simply run:

I’m trying to commit, but Subversion says my working copy is out of date? ¶

Three kinds of situation that can cause this:

Debris from a failed commit is littering your working copy.

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.

If this happens, it’s possible that you have already committed the very changes you are trying now to commit. You can use ‘svn log -rHEAD’ to see if your supposed-failed commit actually succeeded. If it did, run ‘svn revert’ to revert your local changes, then run ‘svn update’ to get your own changes back from the server. (Note that only ‘svn update’ brings your local copies up-to-date; revert doesn’t do that.)

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 Mixed revisions have limitations in the Version Control with Subversion book for details.

You can fix the problem by running ‘svn update’ in the working copy.

You might be genuinely out of date — that is, you’re trying to commit a change to a file that has been changed by someone else since you last updated your copy of that file. Again, ‘svn update’ is the way to fix this.

I’ve contributed a patch to a project and the patch added a new file. Now svn update does not work. ¶

In order to include your new file in the patch you likely ran the svn add command so that the svn diff command would include the new file in the patch. If your patch is committed to the code base and you run an svn update, then you might receive an error message of: «svn: Failed to add file ‘my.new.file’: object of the same name already exists».

The reason that you received this error is that you still have your local copy of the file in your working copy. The steps to correct this problem are:

1. Run the svn revert command to remove the scheduled add within Subversion.
2. Delete the file or move it to a location outside your working copy.
3. Now you should be able to run the svn update command.

You might want to compare the new file from the repository with your original file.

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

Subversion uses a plugin system to allow access to repositories. Currently there are three of these plugins: ra_local allows access to a local repository, ra_neon or ra_serf which allow access to a repository via WebDAV, and ra_svn allows local or remote access via the svnserve server. When you attempt to perform an operation in Subversion, the program tries to dynamically load a plugin based on the URL scheme. A `file://’ URL will try to load ra_local, and an `http://’ URL will try to load ra_neon or ra_serf.

The error you are seeing means that the dynamic linker/loader can’t find the plugins to load. For `http://’ access, this normally means that you have not linked Subversion to neon or serf when compiling it (check the configure script output and the config.log file for information about this). It also happens when you build Subversion with shared libraries, then attempt to run it without first running ‘make install’. Another possible cause is that you ran make install, but the libraries were installed in a location that the dynamic linker/loader doesn’t recognize. Under Linux, you can allow the linker/loader to find the libraries by adding the library directory to /etc/ld.so.conf and running ldconfig. If you don’t wish to do this, or you don’t have root access, you can also specify the library directory in the LD_LIBRARY_PATH environment variable.

I’m getting errors finding or opening a repository, but I know my repository URL is correct. What’s wrong? ¶

When I run `configure’, I get errors about subs-1.sed line 38: Unterminated `s’ command. What’s wrong? ¶

You probably have old copies of /usr/local/bin/apr-config and /usr/local/bin/apu-config on your system. Remove them, make sure the apr/ and apr-util/ that you’re building with are completely up-to-date, and try again.

I’m having trouble building Subversion under Windows with MSVC++ 6.0. What should I do? ¶

Probably you just need to get the latest platform SDK. The one that ships with VC++ 6.0 is not recent enough.

How can I specify a Windows drive letter in a file: URL? ¶

See Subversion Repository URLs in the Subversion Book for more details.

Microsoft Visual Studio 2002 and 2003 seem to have a problem with the «.svn» directory name. What should I do? ¶

Visual Studio can use a web subsystem for ASP.Net, which uses frontpage server extensions to do remote publishing through IIS. This subsystem rejects any pathname that starts with «.». This causes a problem when you try to remotely publish a Subversion working copy, because of the «.svn» subdirectories. The error message says something like «unable to read project information».

To work around this, set the environment variable SVN_ASP_DOT_NET_HACK to any value — this will tell Windows clients to use «_svn» as a directory name in your working copy. See the relevant section of the Subversion 1.3 release notes for more details, and see this question for other ways to customize the administrative directory name.

I’m having trouble doing write operations to a Subversion repository over a network. ¶

For example, one user reported that imports worked fine over local access:

But not from a remote host:

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 dav/ directory (and to db/, of course).

What is the best method of doing a network trace of the conversation between a Subversion client and server? ¶

Why does the svn revert require an explicit target? Why is it not recursive by default? These behaviors differ from almost all the other subcommands. ¶

The short answer: it’s for your own good.

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.

Making the svn revert command require an explicit target—even if that target is just ‘.’—is one way of accomplishing that. This requirement (as well as requiring you to supply the —recursive (-R) 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.

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:

See the Subversion book to learn about configuring access restrictions in Apache.

I’m getting occasional «Access Denied» errors on Windows. They seem to happen at random. Why? ¶

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

On FreeBSD, certain operations (especially svnadmin create) sometimes hang. Why? ¶

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.

I can see my repository in a web browser, but ‘svn checkout’ gives me an error about «301 Moved Permanently». What’s wrong? ¶

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.

For example, if you’ve exported a repository as , but you’ve also set your DocumentRoot to be /www, then you’re in trouble. When the request comes in for /www/foo/bar, apache doesn’t know whether to find a real file named /foo/bar within your DocumentRoot, or whether to ask mod_dav_svn to fetch a file /bar from the /www/foo repository. Usually the former case wins, and hence the «Moved Permanently» error.

The solution is to make sure your repository does not overlap or live within any areas already exported as normal web shares.

It’s also possible that you have an object in the web root which has the same name as your repository URL. For example, imagine your web server’s document root is /var/www and your Subversion repository is located at /home/svn/repo. You then configure Apache to serve the repository at http://localhost/myrepo. If you then create the directory /var/www/myrepo/ this will cause a 301 error to occur.

Compiling with xlc on AIX, I get compilation errors. What’s wrong? ¶

Adding -qlanglvl=extended to the environment variable CFLAGS for configuration and build will make xlc a bit more flexible and the code should compile without error. See https://svn.haxx.se/dev/archive-2004-01/0922.shtml and its associated thread for more details.

I checked out a directory non-recursively (with -N), and now I want to make certain subdirectories «appear». But svn up subdir doesn’t work. ¶

See issue 695. The current implementation of svn checkout -N 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.

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 Apachemodules. ¶

The error message in this case is a little misleading. Most likely Apache is unable to load one or more DLLs that mod_dav_svn.so relies on. If Apache is running as a service it will not have the same PATH as a regular user. Make sure that libdb4*.dll, intl3_svn.dll, libeay32.dll and ssleay32.dll are present in either Apachebin or Apachemodules. You can copy them from your Subversion installation directory if they are not there.

If this still does not resolve the problem, you should use a tool like Dependency Walker on mod_dav_svn.so to see if there are any other unresolved dependencies.

Why aren’t my repository hooks working? ¶

They’re supposed to invoke external programs, but the invocations never seem to happen.

Before Subversion calls a hook script, it removes all 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.

Make sure the hook script is named correctly: for example, the post-commit hook should be named post-commit (without extension) on Unix, and post-commit.bat or post-commit.exe on Windows.

If you’re using Linux or Unix, try running the script «by hand», by following these steps:

1. Use «su», «sudo», or something similar, to become the user who normally would run the script. This might be httpd or www-data, for example, if you’re using Apache; it might be a user like svn if you’re running svnserve and a special Subversion user exists. This will make clear any permissions problems that the script might have.
2. Invoke the script with an empty environment by using the «env» program. Here’s an example for the post-commit hook:

Why does my —diff-cmd complain about ‘-u’? I tried to override it with —extensions, but it’s not working. ¶

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»).

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.

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.

For further information, see issue #2044.

How does Subversion cache credentials (plaintext and encrypted)? ¶

To avoid having to type a password for each server operation, Subversion can cache credentials.

Passwords may have been cached unencrypted by older versions of Subversion («grandfathered in») and Subversion always supports reading these. Whether and how Subversion caches new credentials depends on several factors, including the access method, operating system, compile-time options, and settings in the client’s run-time config file.

To show the credentials in your cache, use svn auth. Credentials are never removed automatically but may be removed manually using svn auth —remove.

Windows

On Windows, Subversion uses standard Windows APIs to encrypt the data, so only the user can decrypt the cached password. (Since Subversion 1.2.)

macOS (formerly Mac OS X)

On macOS, Subversion uses the system Keychain facility to encrypt/store the user’s svn password. (Since Subversion 1.4.)

UNIX/Linux

On UNIX/Linux, Subversion supports up to four credential caches:

• GNOME Keyring
• KWallet
• GPG-Agent
• Plaintext cache in

To determine which credential caches your Subversion client supports, run the svn —version command and look for «The following authentication credential caches are available» toward the end of its output.

GNOME Keyring and KWallet both facilitate storing passwords on disk encrypted. For Subversion to support these programs (since Subversion 1.6), they need to be available at compile-time and at run-time.

TODO: Discuss GPG-Agent.

Depending on a compile-time option (—enable-plaintext-password-storage) and runtime configurations (see below) Subversion may fallback to storing passwords in the Plaintext cache.

The default value of —enable-plaintext-password-storage was changed from True to False in Subversion 1.12, thus disabling the Plaintext cache unless explicitly enabled.

The directory which contains cached Plaintext passwords (usually

/.subversion/auth/) has permissions of 700, meaning only the user (and root) can read them.

«Subversion was compiled with support for Plaintext password cache but I want to prevent writing passwords to the Plaintext cache.»

The following options are available in your run-time config file (per user

/.subversion/servers, systemwide /etc/subversion/config and /etc/subversion/servers):

• To allow encrypted stores like GNOME Keyring and KWallet, but not the Plaintext cache, set store-plaintext-passwords = no.
• To allow caching server certs but not passwords (encrypted or not), set store-passwords = no.
• To disable storing any kind of credentials (encrypted or not) set store-auth-creds = no.

«I want to use the Plaintext cache but it wasn’t enabled at compile time.»

In response to various questions and requests, the Subversion developers have written a Python script that can store a plain-text password to the cache. If you understand the security implications, have ruled out other alternatives, and still want to cache your password in plain-text on disk, you may find the script in the tools/client-side/ directory in (as of this writing) our trunk.

Additional Information

More information on password caching is in Chapter 6 of the Subversion book, under «Client Credentials Caching».

I can’t hotbackup my repository, svnadmin fails on files larger than 2Gb! ¶

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.

I cannot see the log entry for the file I just committed. Why? ¶

Assume you run ‘svn checkout‘ on a repository and receive a working copy at revision 7 (aka, r7) with one file in it called foo.c. You spend some time modifying the file and then commit it successfully. Two things happen:

• The repository moves to a new HEAD revision on the server. The number of the new HEAD revision depends on how many other commits were made since your working copy was checked out. For example, the new HEAD revision might be r20.
• In your working copy, only the file foo.c moves to r20. The rest of your working copy remains at r7.

You now have what is known as a mixed revision working copy. One file is at r20, but all other files remain at r7 until they too are committed, or until ‘svn update‘ is run.

If you run the ‘svn log‘ command without any arguments, it prints the log information for the current directory (named ‘.‘ in the above listing). Since the directory itself is still at r7, you do not see the log information for r20.

To see the latest logs, do one of the following:

1. Run ‘svn log -rHEAD‘.
2. Run ‘svn log URL‘, where URL is the repository URL. If the current directory is a working copy you can abbreviate the URL to the repository root as ^/ to save some typing. Note that on Windows the «^» symbol is special and must be quoted. E.g.: svn log «^/» —limit 10
3. Run ‘svn log URL‘, where URL is the URL of the subdirectory you want to see the log for, for example: svn log ^/trunk
4. Ask for just that file’s log information, by running ‘svn log foo.c‘.
5. Update your working copy so it’s all at r20, then run ‘svn log‘.

Why do I get occasional, seemingly inconsistent errors when checking out over http:// from a repository running on MacOS X 10.4 (Tiger)? ¶

Note: this assumes the repository is being served by Apache 2.0.x.

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 64Kb. The resulting checkout fails, often with unpredictable error messages. Here are some examples of what you might see on the client side, the specific errors may differ for you:

There may also be errors in the Apache error_log, such as:

To confirm the presence of this bug — assuming you have access to the machine that the repository is being served from — try checking out using a file:// URL, which will access the filesystem directly instead of going through Apache. If the resulting checkout completes successfully, then it is almost certain that this is the problem.

Currently, the best solution is to upgrade to APR 1.2.0+.

Alternately, you can rebuild Apache and Subversion from their respective sources, setting the following environment variable before running configure for Apache:

or in Bourne shell syntax, like this:

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.

I can’t build Subversion from working copy source on Debian GNU/Linux; I get errors at the final link stage. What’s wrong? ¶

If you see errors like this in the final link stage of a Subversion trunk source build:

it might be because you’re on a Debian GNU/Linux system and need to upgrade ‘libtool’. (I’ve also heard that the Debian packagers had to tweak ‘libtool’ and that this may cause some problems for Subversion builds. But that’s hearsay — I didn’t have time to verify the details before writing this FAQ entry. However, see https://svn.haxx.se/dev/archive-2006-02/1214.shtml and the thread it spawned for a detailed discussion.)

In any case, after encountering this problem on a Debian GNU/Linux system running a newly-dist-upgraded ‘testing’ distribution on 15 Nov 2005, the solution was to build libtool 1.5.20 from source, using the standard «./configure && make && sudo make install» recipe. After that, I did a ‘make clean’ in my Subversion working copy tree, ‘./autogen.sh’, ‘./configure’, ‘make’, and everything worked fine.

Note that another report of these symptoms appeared at https://svn.haxx.se/dev/archive-2003-01/1125.shtml, though the solution described here was not mentioned in that thread.

I’ve started svnserve, but it doesn’t seem to be listening on port 3690. ¶

Invoke svnserve with the —listen-host=0.0.0.0 option. Svnserve does not properly support IPv4/IPv6 dual-stack operation. See issue #2382.

I can’t add a directory because Subversion says it’s «already under version control». ¶

The directory you’re trying to add already contains a .svn subdirectory — it is a working copy — but it’s from a different repository location than the directory to which you’re trying to add it. This probably happened because you used your operating system’s «copy» command (instead of svn copy) to copy a subdirectory in this working copy, or to copy some other working copy into this one.

The quick and dirty solution is to delete all .svn directories contained in the directory you’re trying to add; this will let the «add» command complete. If you’re using Unix, this command will delete .svn directories under dir:

However, if the copy was from the same repository, you should ideally delete or move aside the copy, and use svn copy to make a proper copy, which will know its history and save space in the repository.

If it was from a different repository, you should ask yourself why you made this copy; and you should ensure that by adding this directory, you won’t be making an unwanted copy of it in your repository.

Accessing non-public repositories via svnserve is really slow sometimes. ¶

This often happens when APR is compiled to use /dev/random and the server is unable to gather enough entropy. If Subversion is the only application using APR on the server, you can safely recompile APR with the —with-devrandom=/dev/urandom option passed to configure. This should not be done on systems that use APR for other processes, however, as it could make other services insecure.

When performing Subversion operations involving a lot of data over SSL, I get the error SSL negotiation failed: SSL error: decryption failed or bad record mac. ¶

This can occur due to a problem with OpenSSL 0.9.8. Downgrading to an older version (or possibly upgrading to a newer version) is known to fix this issue.

I get an error that says «This client is too old». ¶

Why doesn’t svn switch work in some cases? ¶

In some cases where there are unversioned (and maybe ignored) items in the working copy, svn switch can get an error. The switch stops, leaving the working copy half-switched.

Unfortunately, if you take the wrong corrective action you can end up with an unusable working copy. Sometimes with these situations, the user is directed to do svn cleanup. But the svn cleanup may also encounter an error. See issue #2505.

The user can manually remove the directories or files causing the problem, and then run svn cleanup, and continue the switch, to recover from this situation.

Note that a switch from a pristine clean checkout always works without error. There are three ways of working if you are using svn switch as part of your development process:

Fully clean your working copy of unversioned (including ignored) files before switching.
WARNING! This deletes all unversioned dirs/files. Be VERY sure that you do not need anything that will be removed.

Some examples are detailed here in issue 2505. The problem is that the svn client plays it safe and doesn’t want to delete anything unversioned.

Two specific examples are detailed here to illustrate a problem like this. There are also other svn switch errors, not covered here, which you can avoid by switching only from a pristine checkout.

If any directory has been moved or renamed between the branches, then anything unversioned will cause a problem. In this case, you’ll see this error:

Removing all unversioned files, and continuing the switch will recover from this.

If a temporary build file has ever been added and removed, then a switch in a repository with that unversioned file (likely after a build) fails. You’ll see the same error:

In this case, just removing the unversioned items will not recover. A cleanup fails, but «svn switch» directs you to run «svn cleanup».

Removing the directory (and all other unversioned files, to prevent «switch» from breaking on a similar error repeatedly), and continuing the switch will recover from this.

The TortoiseSVN cleanup error is a bit different. You might encounter this:

In each case here, the «svn switch» breaks leaving you with a half-switched working copy. «svn status» will show items with S for switched items (different from top directory), ! for directories with problems, and

for the files that are the problem (and with maybe L for locked). Like this:

In Windows, when doing an update with the command-line client, I get an error saying «The system cannot find the path specified» and suggesting that my working copy might be corrupt. But I can update with TortoiseSVN just fine. What’s going on? ¶

A careful examination of the Windows API documentation regarding Naming a File reveals the most common reason why this happens. In short, you can address significantly longer path names when using the Unicode versions of the Windows path functions, and providing absolute path specifiers instead of relative path specifiers. Fortunately, the Apache Portable Runtime (APR) library that Subversion uses transparently converts absolute paths (like C:WorkingCopyfile.txt) into the form required by the Windows APIs (\?C:WorkingCopyfile.txt), and back again. Unfortunately, you only get these long-path benefits when using absolute paths.

To see if path length is the reason for the problem you’re seeing, try providing an absolute target path to the Subversion command-line client instead of a relative one (or none at all). In other words, instead of doing this:

If the problem goes away, congratulations — you’ve hit a Windows path length limitation. And now you know the workaround.

Why does this problem not affect TortoiseSVN? Because TortoiseSVN always provides absolute paths to the Subversion APIs.

Why, then, does the Subversion command-line client not always convert its input into absolute paths and use those? It does, as of Subversion 1.7.

I got an error saying «This client is too old to work with working copy ‘. ‘ «. How can I fix it without upgrading Subversion? ¶

Sometimes the working copy metadata format changes incompatibly between minor releases. For example, say you have a working copy created with Subversion 1.4.4, but one day you decide to try out Subversion 1.5.0. Afterwards, you attempt to switch back to 1.4.4, but it doesn’t work — it just gives the above error.

This is because 1.5.0 upgraded your working copy format to support some new features (in this case, changelists, the keep-local flag, and variable-depth directories). Although 1.4.4 doesn’t know anything about these new features, it can at least recognize that the working copy format has been upgraded to something higher than it can handle.

1.5.0 upgraded the working copy for a good reason: it realizes that 1.4.4 does not know about these new features, and that if 1.4.4 were to meddle with the working copy metadata now, important information might be lost, possibly causing corruption (see issue #2961, for example).

Subversion 1.7.0 and newer will not upgrade working copies unless you explicitly ask them to do so. (Upgrading the working copies is, however, required; Subversion 1.7.0 cannot operate on working copies created or used by earlier Subversions.)

Subversion 1.6.x and earlier automatically upgrade working copies when they first touch them. This behavior can be annoying, if you just want to try out a new release of Subversion without installing it permanently. For this reason, we distribute a script that can downgrade working copies when doing so is safe:

Run that script with the «—help» option to see how to use it. (It can downgrade 1.6.x working copies to formats usable by Subversion 1.4.x and 1.5.x, but cannot downgrade 1.7.x working copies.)

As future versions of Subversion are released, we will try to keep this FAQ entry up-to-date with potential downgrade scenarios and their implications.

I got an error saying «relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object» when building the Neon library on 64-bit Linux. ¶

The Neon library, used for communication between a Subversion server and client over HTTP, is usually built as a static library. But it is subsequently linked into a different shared library. This causes an error during the build process on 64-bit AMD systems similar to this:

There was a thread on the developers’ list about this.

The solution is to supply the «—enable-shared» option to Subversion’s configure script.

Why am I getting an error saying «Could not read response body: Secure connection truncated» when doing a checkout from Apache? ¶

In short, this error is representative of a class of problems which can occur when Apache erroneously believes that your Subversion client is no longer tending to the network connection it has made with Apache. Other error messages have been reported in similar circumstances, depending on whether or not SSL was in use for the connection, or when exactly Apache decided that the connection should be terminated.

The Subversion client tries to keep working copies in a sane state at all times. One way it does this during checkouts is by squirreling away the pristine versions of checked-out files until all the files and subdirectories for a given directory have been fetched. Once all the data for a directory has been downloaded, the client «finalizes» that directory, copying the pristine versions of files out into the working area, diddling administrative data, and so on. While this directory finalization is happening, the client is focused on that task and is not tending to the checkout network stream. Sometimes — typically in situations where a versioned directory contains an abnormally large number of files, or a bunch of abnormally large files — the client can spend so much time finalizing a directory (and ignoring the network stream) that Apache thinks the client has gone away for good, so Apache terminates the connection. When the client finally turns its attention back to the network stream, it finds that the server has given up on the connection, and it reports this as an error.

One workaround for this situation is to increase the amount of time Apache is willing to wait for a client to prove it is still listening to the network stream. You do this by adjusting upward the Apache Timeout configuration value. You are encouraged, however, to evaluate your data set. If having a huge number of files in a single directory is causing problems for you during checkouts, there is some chance that it will cause additional problems elsewhere, too. If it is possible for you to split your collection of files up into a few subdirectories with smaller file counts, this could prove universally beneficial.

Why am I getting a tree conflict upon update even though no one else has committed conflicting changes? ¶

When you commit, only the files/directories that are actually changed by the commit get their base revisions bumped to HEAD in the working copy. The other files/directories (possibly including the directory you committed from!) don’t get their base revisions bumped, which means Subversion still considers them to be based on outdated revisions. See also this question and this section of the Subversion book.

This can be confusing, in particular because of tree conflicts you can inflict upon yourself. E.g. if you add a file to a directory and commit, and then locally move that directory somewhere else, and then try to commit, this second commit will fail with an out-of-date error since the directory itself is still based on an out-of-date revision. When updating, a tree conflict will be flagged.

Subversion has currently no way of knowing that you yourself just committed the change which caused the directory to be out-of-date during the second commit. And allowing an out-of-date directory to be committed may cause certain tree conflicts not to be detected, so Subversion can’t allow you to do this.

To avoid this problem, make sure to update your entire working copy before making structural changes such as deleting, adding, or moving files or directories.

When performing Subversion operations over SSL, I get the error SSL handshake failed: SSL error code -1/1/336032856. ¶

This can happen when the hostname reported by the server does not the match hostname given in the SSL certificate. Make sure your server configuration uses correct values for ServerName and NameVirtualHost.

A client-side fix is to update OpenSSL to version 1.0.0d. See this post to the Subversion developer mailing list for details.

I get «Error validating server certificate» error even though I configure the SSL certificates correctly in the server. ¶

This error occurs if the certificate issuer is not recognized as ‘Trusted’ by the SVN client. Subversion will ask you whether you trust the certificate and if you want to store this certificate.

In some cases, even if you accept this by entering ‘p’ option, the next time you access SVN, the same error appears again. There can be multiple reasons. The problem may be your

/.subversion directory has wrong permissions, so that each time you want to permanently add the credentials, svn actually cannot do so, and also doesn’t inform you that it can’t.

This can be solved by either fixing the permissions with chmod 644 in

directory or by deleting the directory contents. If deleted, the directory gets populated automatically the next time you access the repository.

After importing files to my repository, I don’t see them in the repository directory. Where are they? ¶

The files are in the repository; you can verify this by running commands such as svn ls -R, or by trying to checkout a working copy from the repository:

The versioned files and directories are simply not stored on-disk in a tree format (like CVS repositories used to), but instead are stored in database files. The BDB backend uses Berkeley DB databases, and the FSFS backend uses both a custom file format and may in the future use SQLite databases.

When does svn copy create svn:mergeinfo properties? ¶

In general, to avoid some kinds of spurious merge conflicts, the following rules can be kept in mind:

• When copying/renaming a file or directory within the trunk or a branch, perform the copy/rename in a working copy. For renames, the working copy should not be a mixed-revision working copy.
• When copying/renaming an entire branch, perform the copy/rename in the repository (i.e. via URLs).

During copies where the source is a URL, and the target is either a URL or in a working copy, explicit mergeinfo is created on the copy target. This is done so that when a branch is created with and later an ancestrally unrelated subtree is copied into the branch using an invocation such as the directory /branches/mybranch/bar does not inherit mergeinfo from its parent /branches/mybranch. Mergeinfo inherited from the parent might not reflect the factually correct merge history of the new child.

During copies where both the source and the target are within a working copy, no mergeinfo is created on the copy target (as of Subversion 1.5.5). This assumes the case where a new child is added on the trunk (or a branch), and this addition is merged to another branch which is kept in sync using periodic catch-up merges. In this case, the inherited mergeinfo of the branch’s new child is correct, and the creation of explicit mergeinfo could cause spurious merge conflicts due to apparent, but factually inaccurate, differences in the child’s and parent’s merge histories.

For additional details and discussion about this behaviour, see this post on the users mailing list.

Passwords which contain some special characters do not seem to be working? ¶

Passwords which contain non-ASCII characters may not work reliably with the basic authentication mechanisms Subversion supports. This is due to potential character encoding differences between the client and server systems. See this mailing list post for details.

As a workaround, you can configure your Subversion server to use a single-sign-on mechanism, such as Kerberos or SSPI. See the Apache HTTPD server documentation for details. If you are using svnserve, see the ‘Using svnserve with SASL’ chapter in the Subversion book.

When using svnserve with SSH authentication SSH keys can be used to work around this limitation of passwords.

Why does an HTTP(S) URL-to-URL copy or branch/tag operation take a long time? ¶

If you are seeing slow server-side copying (a.k.a. branching or tagging) with a Subversion repository served over HTTP(S), you might be running into issue 4531. This problem is caused by a crawl of the “tree-to-copy” by httpd’s mod_dav module on the server (giving the copy a performance cost of O(sizeof(tree)) instead of SVN’s usual O(1) for branching/tagging). This behaviour is present in Apache httpd version 2.2.25 (or higher) and 2.4.6 (or higher) – older versions of httpd are not affected. Branching/tagging a large tree may take several minutes because of this.

This problem has been fixed in mod_dav_svn in Subversion 1.8.14. You can also use the following workaround to make mod_dav skip the unnecessary work; add the following directives to the Apache configuration on the server, preferably only inside the Location blocks configured for SVN:

This adds a request header «Depth» with value 0 to each COPY request. This makes mod_dav avoid the crawl of the tree being copied (yet still lets Subversion perform a normal recursive copy).

When performing Subversion operations over SSL, I get the error An error occurred during SSL communication ¶

SSL communication errors can have various reasons. You can use the openssl binary to debug the ssl connection. If you use a client certificate, then you need to convert Subversion’s client certificate from pkcs12 to pem first: Then you can use: If you are using ssl-authority-files in .subversion/servers to verify the server cert you can get s_client to do the same with the additional parameter: The s_client output may indicate what problem is occurring.

For example, if s_client reports then creating new CA keys with sha256 instead of md5 should solve the problem.

Developer questions: ¶

How do I run the regression tests in a RAM disk? ¶

How do I run a debugger on dynamic Subversion binaries without having to install them? ¶

Before the make install step on unix-y systems, dynamically built «executables» in a Subversion source tree are actually libtool-generated shell scripts which re-link and run the real binary. As shown below, this complicates debugging:

You can work around this by running gdb via the libtool command. The libtool command in execute mode will detect that the svn command is a libtool wrapper script and handle setting the appropriate environment variables and replace the script with the path to the real file before running gdb..

Your command line would look something like this:

How do I run a debugger on Subversion binaries without compiler inlining obfuscating the source? ¶

By default, gcc will often optimize away private variables and functions, inlining the associated operations. This can complicate stepping through the code in a debugger.

Work around this by turning off optimization during the make step on unix-y systems:

(That’s «dash ohh zero».) Alternately, you can make this change more permanent by running configure as follows:

For a production install, remember to undo this operation before installing Subversion from source, by re-running make or configure without the extra flag.

References: ¶

What are all the HTTP methods Subversion uses? ¶

The Subversion client speaks a subset the WebDAV/DeltaV protocol to the mod_dav_svn server module. The short answer is:

Note that this list may grow over time: Subversion 1.7+ started using the POST method when speaking to 1.7+ servers, and it’s possible that Subversion 1.9+ might start using yet another method when talking to 1.9+ servers.

The details of the protocol are documented here:

What’s a ‘bikeshed’? ¶

How do you pronounce «Subversion»? ¶

Jim Blandy, who gave Subversion both its name and repository design, pronounces «Subversion» «Subversion».

What’s a ‘baton’? ¶

Throughout Subversion’s source code there are many references to ‘baton’ objects. These are just void * data structures that provide context to a function. In other APIs, they’re often called void *ctx or void *userdata Subversion developers call the structures «batons» because they’re passed around quite a bit.

What do you mean when you say that repository is ‘wedged’? ¶

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 this entry for details how to do that.

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.

You might also like to check The Jargon File’s definition for ‘wedged’.

What is CVSSv3 and what do the score and vector mean? ¶

Subversion is using CVSSv3 in our security advisories so you will see a CVSSv3 Base Score and Vector in the Severity section of our advisories. CVSSv3 is the current version of the Common Vulnerability Scoring System which is an open industry standard for assessing the severity of computer system security vulnerabilities. FIRST maintains the documentation for the standard.

The score is a number in the range of 0 to 10 with less risky vulnerabilities scoring lower and more risky vunerabilities scoring higher. The score is calculated by determining the metrics of the vunerability and then calculating the score based on those metrics. If you want to understand how a score was determined you would need the vector and an understanding of the formula as specified by the standard.

The vector is an abbreviated description of the metrics that apply to the vulnerability.

CVSSv3 provides for 3 types of metrics and scores; base, temporal and environmental. The Subversion project will only ever provide the base score and metrics. As a project we cannot determine the environmental risks of the various installations so it is not possible for us to calculate the environmental metrics. The temporal metrics are for factors that may change over time. We do not update our advisories once published so it’s not possible for us to track these changing values.

Some vulnerabilities require specific configurations or environmental factors in order to be exploited. CVSSv3 specifies that the Access Complexity metric consider how common such a configuration is. As a result, a vulnerability that requires an unusual configuration will have a low score. The scores can help you prioritize how quickly you need to react to an advisory but as a result of the Access Complexity metric you should still consider how the vulnerability impacts your installation.

When calculating the Availability Impact metric of server vulnerabilities the Subversion project will use the value of Complete within the context of Subversion and not the host system. For example when considering a Denial of Service attack the Availability Impact metric will be calculated as High if the vulnerability allows an attacker to make the Subversion server completely inaccessible. On the other hand if the attack only made the Subversion server slow or limited the number of successful connections it would be rated as Low.

When calculating the Integrity Impact metric of server vulnerabilities the Subversion project will use the value of High when history of the Subversion repositories may be changed or when the ability to modify any file on the host system occurs. The ability to change any file (while leaving the appropriate history trail) in violation of any authentication or authorization requirements will be treated as Low.

When calculating the Confidentiality Impact metric of server vulnerabilities the Subversion project will use the value of High when all files in the repository may be read regardless of any authentiation or authorizaiton requirements. If only some files may be read it will be considered Low.

As a result of how we calculate these impact metrics you may see advisories in vulnerability databases or vendor advisories that have a different score. For instance an Linux distribution that provides a binary package of Subversion may score the full exposure of the contents of the Subversion repository hosted on the system as only a Low Confidentiality Impact, resulting in a lower score.

Источник