accidentally deleted content of ~/.subversion/servers file - wanted: default content? - related: signed using insecure algorithm svn error

Question

is there any initial content of ~/.subversion/servers config file? I tried to look in the source code, but it's almost impossible to figure out ... :/

This was the only hint i found so far. But anyway, it's not really solving the issue. http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html#svn.advanced.confarea.windows-registry.ex-1

My problem is that i wanted to workaround the no "Certificate verification error: signed using insecure algorithm" error by appending to the ~/.subversion/servers file "ssl-trust-default-ca = no".

So far it's not working, becaus i just deleted the content somehow using terminal "vi" editor. The line itself and alone in the servers-File generates another error: "~/.subversion/servers:2: Section header expected"

What i have undertaken so far is adding some of the contents taken from the link i posted above. This results in the ~/.subversion/servers file being: "

    #Servers
    #
    #The servers file contains Subversion configuration options related to the network layers. There are two special sections in this file—[groups] and [global]. The [groups] section is essentially a cross-reference table. The keys in this section are the names of other sections in the file; their values are globs—textual tokens that possibly contain wildcard characters—that are compared against the hostnames of the machine to which Subversion requests are sent.
    #
    [groups]
    #beanie-babies = *.red-bean.com
    #collabnet = svn.collab.net
    #
    [beanie-babies]
    #…
    #
    [collabnet]
    #…
    #When Subversion is used over a network, it attempts to match the name of the server it is trying to reach with a group name under the [groups] section. If a match is made, Subversion then looks for a section in the servers file whose name is the matched group's name. From that section, it reads the actual network configuration settings.
    #
    #The [global] section contains the settings that are meant for all of the servers not matched by one of the globs under the [groups] section. The options available in this section are exactly the same as those that are valid for the other server sections in the file (except, of course, the special [groups] section), and are as follows:
    #
    #http-auth-types
    #This is a semicolon-delimited list of HTTP authentication types which the client will deem acceptable. Valid types are basic, digest, and negotiate, with the default behavior being acceptance of any these authentication types. A client which insists on not transmitting authentication credentials in cleartext might, for example, be configured such that the value of this option is digest;negotiate—omitting basic from the list. (Note that this setting is only honored by Subversion's Neon-based HTTP provider module.)
    #
    #http-compression
    #This specifies whether Subversion should attempt to compress network requests made to DAV-ready servers. The default value is yes (though compression will occur only if that capability is compiled into the network layer). Set this to no to disable compression, such as when debugging network transmissions.
    #
    #http-library
    #Subversion provides a pair of repository access modules that understand its WebDAV network protocol. The original one, which shipped with Subversion 1.0, is libsvn_ra_neon (though back then it was called libsvn_ra_dav). Newer Subversion versions also provide libsvn_ra_serf, which uses a different underlying implementation and aims to support some of the newer HTTP concepts.
    #
    #At this point, libsvn_ra_serf is still considered experimental, though it appears to work in the common cases quite well. To encourage experimentation, Subversion provides the http-library runtime configuration option to allow users to specify (generally, or in a per-server-group fashion) which WebDAV access module they'd prefer to use—neon or serf.
    #
    #http-proxy-exceptions
    #This specifies a comma-separated list of patterns for repository hostnames that should be accessed directly, without using the proxy machine. The pattern syntax is the same as is used in the Unix shell for filenames. A repository hostname matching any of these patterns will not be proxied.
    #
    #http-proxy-host
    #This specifies the hostname of the proxy computer through which your HTTP-based Subversion requests must pass. It defaults to an empty value, which means that Subversion will not attempt to route HTTP requests through a proxy computer, and will instead attempt to contact the destination machine directly.
    #
    #http-proxy-password
    #This specifies the password to supply to the proxy machine. It defaults to an empty value.
    #
    #http-proxy-port
    #This specifies the port number on the proxy host to use. It defaults to an empty value.
    #
    #http-proxy-username
    #This specifies the username to supply to the proxy machine. It defaults to an empty value.
    #
    #http-timeout
    #This specifies the amount of time, in seconds, to wait for a server response. If you experience problems with a slow network connection causing Subversion operations to time out, you should increase the value of this option. The default value is 0, which instructs the underlying HTTP library, Neon, to use its default timeout setting.
    #
    #neon-debug-mask
    #This is an integer mask that the underlying HTTP library, Neon, uses for choosing what type of debugging output to yield. The default value is 0, which will silence all debugging output. For more information about how Subversion makes use of Neon, see Chapter 8, Embedding Subversion.
    #
    #ssl-authority-files
    #This is a semicolon-delimited list of paths to files containing certificates of the certificate authorities (or CAs) that are accepted by the Subversion client when accessing the repository over HTTPS.
    #
    #ssl-client-cert-file
    #If a host (or set of hosts) requires an SSL client certificate, you'll normally be prompted for a path to your certificate. By setting this variable to that same path, Subversion will be able to find your client certificate automatically without prompting you. There's no standard place to store your certificate on disk; Subversion will grab it from any path you specify.
    #
    #ssl-client-cert-password
    #If your SSL client certificate file is encrypted by a passphrase, Subversion will prompt you for the passphrase whenever the certificate is used. If you find this annoying (and don't mind storing the password in the servers file), you can set this variable to the certificate's passphrase. You won't be prompted anymore.
    #
    #ssl-pkcs11-provider
    #The value of this option is the name of the PKCS#11 provider from which an SSL client certificate will be drawn (if the server asks for one). This setting is only honored by Subversion's Neon-based HTTP provider module.
    #
    ssl-trust-default-ca = no
    #Set this variable to yes if you want Subversion to automatically trust the set of default CAs that ship with OpenSSL.
    #
    #store-auth-creds
    #This setting is the same as store-passwords, except that it enables or disables on-disk caching of all authentication information: usernames, passwords, server certificates, and any other types of cacheable credentials.
    #
    #store-passwords
    #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 regarding that, see the section called “Caching credentials”. Note that regardless of how this option is configured, Subversion will not store passwords in plaintext unless the store-plaintext-passwords option is also set to yes.
    #
    #store-plaintext-passwords
    #This variable is only important on UNIX-like systems. It controls what the Subversion client does in case the password for the current authentication realm can only be cached on disk in unencrypted form, in the ~/.subversion/auth/ caching area. You can set it to yes or no to enable or disable caching of passwords in unencrypted form, respectively. The default setting is ask, which causes the Subversion client to ask you each time a new password is about to be added to the ~/.subversion/auth/ caching area.
    #
    #store-ssl-client-cert-pp
    #This option controls whether Subversion will cache SSL client certificate passphrases provided by the user. Its value defaults to yes. Set this to no to disable this passphrase caching.
    #
    #store-ssl-client-cert-pp-plaintext
    #This option controls whether Subversion, when attempting to cache an SSL client certificate passphrase, will be allowed to do so using its on-disk plaintext storage mechanism. The default value of this option is ask, which causes the Subversion client to ask you each time a new client certificate passphrase is about to be added to the ~/.subversion/auth/ caching area. Set this option's value to yes or no to indicate your preference and avoid related prompts.

"

[i thank stackoverflow so much, my browser crashed twice while writing, but the message was somehow restored! godness, and it's one of the helpful sites in this virtual times, where time is gone, thanks]

Ah yes, what helped me with the certificate error so far, was from this page: http://linux-knowledgebase.com/en/Tip_of_the_day/December/Certificate_verification_error%253A_signed_using_insecure_algorithm

Answer 1

If you want the default .subversion directory, rename your current .subversion directory, run an svn command and it will create a fresh one for you. For example:

$ mv .subversion .subversion-
$ svn info
svn: '.' is not a working copy
$ ls -dl .subversion*
drwxr-xr-x 3 vobadm g268 4096 Jun 19 15:12 .subversion
drwxr-xr-x 3 vobadm g268 4096 Jun 19 15:12 .subversion-

Then you could try to re-do your changes in the fresh directory, and the old files will still be there to refer to. I think that would be easier than trying to recontruct that config file from scratch.

The other advantage to doing this is that if Subversion has been upgraded since your .subversion directory was created, any new settings will be listed in the (newly created) default config files.