This instructs Subversion to cache, or not to cache, passwords that are supplied by the user in response to server authentication challenges. The default value is yes. Set this to no to disable this on-disk password caching. You can override this option for a single instance of the svn command using the --no-auth-cache command-line parameter (for those subcommands that support it). For more information, see the section called “Client Credentials Caching”.

This setting is the same as store-passwords, except that it enables or disables disk-caching of all authentication information: usernames, passwords, server certificates, and any other types of cacheable credentials.

This specifies the program Subversion will use to query the user for certain types of textual metadata or when interactively resolving conflicts. See the section called “Using External Editors” for more details on using external text editors with Subversion.

This specifies the absolute path of a differencing program, used when Subversion generates “diff” output (such as when using the svn diff command). By default Subversion uses an internal differencing library—setting this option will cause it to perform this task using an external program. See the section called “Using External Differencing and Merge Tools” for more details on using such programs.

This specifies the absolute path of a three-way differencing program. Subversion uses this program to merge changes made by the user with those received from the repository. By default Subversion uses an internal differencing library—setting this option will cause it to perform this task using an external program. See the section called “Using External Differencing and Merge Tools” for more details on using such programs.

This flag should be set to true if the program specified by the diff3-cmd option accepts a --diff-program command-line parameter.

This specifies the program that Subversion will use to perform three-way merge operations on your versioned files. See the section called “Using External Differencing and Merge Tools” for more details on using such programs.

When running the svn status command, Subversion lists unversioned files and directories along with the versioned ones, annotating them with a ? character (see the section called “See an overview of your changes”). Sometimes, it can be annoying to see uninteresting, unversioned items—for example, object files that result from a program's compilation—in this display. The global-ignores option is a list of whitespace-delimited globs which describe the names of files and directories that Subversion should not display unless they are versioned. The default value is *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store.

As well as svn status, the svn add and svn import commands also ignore files that match the list when they are scanning a directory. You can override this behaviour for a single instance of any of these commands by explicitly specifying the file name, or by using the --no-ignore command-line flag.

For information on more fine-grained control of ignored items, see the section called “Ignoring Unversioned Items”.

This instructs Subversion to automatically set properties on newly added or imported files. The default value is no, so set this to yes to enable Auto-props. The auto-props section of this file specifies which properties are to be set on which files.

This variable sets the default character set encoding for commit log messages. It's a permanent form of the --encoding option (see the section called “svn Options”). The Subversion repository stores log messages in UTF-8, and assumes that your log message is written using your operating system's native locale. You should specify a different encoding if your commit messages are written in any other encoding.

Normally your working copy files have timestamps that reflect the last time they were touched by any process, whether that be your own editor or by some svn subcommand. This is generally convenient for people developing software, because build systems often look at timestamps as a way of deciding which files need to be recompiled.

In other situations, however, it's sometimes nice for the working copy files to have timestamps that reflect the last time they were changed in the repository. The svn export command always places these “last-commit timestamps” on trees that it produces. By setting this config variable to yes, the svn checkout, svn update, svn switch, and svn revert commands will also set last-commit timestamps on files that they touch.

This option, new to Subversion 1.5, specifies the path of a MIME types mapping file, such as the mime.types file provided by the Apache HTTP Server. Subversion uses this file to assign MIME types to newly added or imported files. See the section called “Automatic Property Setting” and the section called “File Content Type” for more about Subversion's detection and use of file content types.

The value of this option is a space-delimited list of file extensions which Subversion should preserve when generating conflict file names. By default, the list is empty. This option is new to Subversion 1.5.

When Subversion detects conflicting file content changes, it defers resolution of that conflict to the user. To assist in the resolution, Subversion keeps pristine copies of the various competing versions of the file in the working copy. By default, those conflict files have names constructed by appending to the original file name a custom extension such as .mine or .REV (where REV is a revision number). A mild annoyance with this naming scheme is that on operating systems where a file's extension determines the default application used to open and edit that file, appending a custom extension prevents the file from being easily opened by its native application. For example, if the file ReleaseNotes.pdf was conflicted, the conflict files might be named ReleaseNotes.pdf.mine or ReleaseNotes.pdf.r4231. While your system might be configured to use Adobe's Acrobat Reader to open files whose extensions are .pdf, there probably isn't an application configured on your system to open all files whose extensions are .r4321.

You can fix this annoyance by using this configuration option, though. For files with one of the specified extensions, Subversion will append to the conflict file names the custom extension just as before, but then also re-append the file's original extension. Using the previous example, and assuming that pdf is one of the extensions configured in this list thereof, the conflict files generated for ReleaseNotes.pdf would instead be named ReleaseNotes.pdf.mine.pdf and ReleaseNotes.pdf.r4231.pdf. Because each of these files end in .pdf, the correct default application will be used to view them.

This is a boolean option which specifies whether or not Subversion should try to resolve conflicts interactively. If its value is yes (which is the default value), Subversion will prompt the user for how to handle conflicts in the manner demonstrated in the section called “Resolve Conflicts (Merging Others' Changes)”. Otherwise, it will simply flag the conflict and continue its operation, postponing resolution to a later time.

This boolean option corresponds to the --no-unlock option to svn commit, which tells Subversion not to release locks on files you've just committed. If this runtime option is set to yes, Subversion will never release locks automatically, leaving you to run svn unlock explicitly. It defaults to no.