Cette liste délimitée par des virgules spécifie quel magasin de stockage de mot de passe (s'il en existe) Subversion doit utiliser pour sauver et récupérer les éléments d'authentification. Elle indique également dans quel ordre Subversion doit les essayer. La valeur par défaut est gnome-keyring, kwallet, keychain, gpg-agent, windows-crypto-api qui désigne respectiviement le trousseau GNOME, celui de KDE, celui de Mac OS X, l'agent GnuPG et l'API cryptographique de Microsoft Windows. Les magasins qui ne sont pas disponibles sur le système sont ignorés.

Cette option est obsolète dans le fichier config. Elle fait maintenant partie de la configuration propre à chaque serveur dans le fichier servers. Reportez-vous à la section intitulée « Configuration spécifique à un serveur » pour plus de détails.

Cette option est obsolète dans le fichier config. Elle fait maintenant partie de la configuration propre à chaque serveur dans le fichier servers. Reportez-vous à la section intitulée « Configuration spécifique à un serveur » pour plus de détails.

Spécifiez ici le chemin absolu vers un programme que Subversion utilisera pour générer l'affichage « diff » (celui produit par la commande svn diff). Par défaut, Subversion utilise une bibliothèque interne pour les deltas. Si vous spécifiez une valeur, Subversion utilisera ce programme tiers. Lisez la section intitulée « Utilisation des outils externes de comparaison et de fusion » pour plus de détails sur l'utilisation de tels programmes.

Comme pour l'option en ligne de commande --extensions (-x), spécifiez ici les options complémentaires que vous souhaitez passer au programme tiers des deltas. L'ensemble des options ayant un sens varie en fonction du programme utilisé pour traiter les deltas. Lisez la sortie produite par svn help diff pour obtenir des détails. La valeur par défaut de cette option est -u.

Spécifiez ici le chemin absolu vers un programme de traitement des deltas à trois entrées. Subversion utilisera ce programme pour fusionner les changements effectués par l'utilisateur avec ceux reçus par le dépôt. Par défaut, Subversion utilise une bibliothèque interne de traitement des deltas. Si vous spécifiez une valeur, Subversion utilisera ce programme tiers. Reportez-vous à la section intitulée « Utilisation des outils externes de comparaison et de fusion » pour plus de détails sur l'utilisation de tels programmes.

Cette option binaire doit être positionnée à true si le programme spécifié par l'option diff3-cmd accepte comme paramètre l'option --diff-program.

Spécifiez ici le programme que Subversion utilisera pour demander à l'utilisateur de renseigner des métadonnées ou pour résoudre des conflits de manière interactive. Lisez la section intitulée « Utilisation d'éditeurs externes » pour plus de détails sur l'utilisation d'éditeurs de textes tiers avec Subversion.

Spécifiez ici le programme tiers que Subversion utilisera pour effectuer des fusions à trois entrées sur vos fichiers suivis en versions. Lisez la section intitulée « Utilisation des outils externes de comparaison et de fusion » pour plus de détails sur l'utilisation de tels programmes.

Elle demande à Subversion d'ajouter automatiquement des propriétés sur les fichiers ajoutés ou importés. La valeur par défaut est no (c'est-à-dire non), vous devez donc la basculer sur yes pour activer la fonctionnalité. La section [auto-props] de ce fichier spécifie quelles propriétés doivent être définies sur ces fichiers.

Lorsque vous lancez la commande svn status, Subversion liste les fichiers et dossiers non suivis en versions avec ceux suivis en versions, en les notant avec le caractère ? (voir la section intitulée « Vue d'ensemble des changements effectués »). Parfois, il n'est pas commode de voir ces éléments non suivis en versions sans intérêt (par exemple les fichiers objets produits par la compilation du programme) dans la sortie de la commande. L'option global-ignores est une liste de motifs, séparés par des espaces, qui décrit les noms de fichiers et dossiers que Subversion doit ignorer sauf s'ils sont suivis en versions. La valeur par défaut est *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store.

De la même façon que svn status, les commandes svn add et svn import ignorent les fichiers qui correspondent aux éléments de la liste quand ils passent en revue un dossier. Vous pouvez redéfinir ce comportement pour une exécution de chacune de ces commandes en spécifiant explicitement le nom de fichier ou en utilisant l'option binaire --no-ignore en ligne de commande.

Pour plus d'informations sur la gestion des éléments à ignorer, reportez-vous à la section intitulée « Occultation des éléments non suivis en versions ».

C'est une option booléenne qui spécifie si Subversion doit essayer de résoudre les conflits en mode interactif. Si cette valeur est yes (ce qui est la valeur par défaut), Subversion demandera à l'utilisateur d'indiquer comment traiter les conflits comme cela a été montré dans la section intitulée « Résolution des conflits ». Sinon, il annotera les fichiers comme étant en conflit et continue son opération, reportant la résolution à plus tard.

Cette variable définit l'encodage des caractères pour les commentaires de propagations. C'est une forme permanente de l'option --encoding (voir Options de svn). Le dépôt Subversion stocke les commentaires de propagation en UTF-8 et suppose que vos commentaires de propagations sont écrits en utilisant l'encodage par défaut de votre système. Vous pouvez donc spécifier ici l'encodage utilisé pour vos commentaires de propagation si ceux-ci sont écrits en utilisant un encodage différent.

Cette option, apparue avec Subversion 1.5, spécifie le chemin d'un fichier de correspondance pour les types MIME, sur le même modèle que le fichier mime.types des serveurs HTTP Apache. Subversion utilise ce fichier pour associer un type MIME aux fichiers qui viennent d'être ajoutés ou importés. Lisez la section intitulée « Configuration automatique des propriétés » et la section intitulée « Type de contenu des fichiers » pour plus d'informations sur la détection et l'utilisation du type des fichiers par Subversion.

Cette option booléenne correspond à l'option --no-unlock de la commande svn commit. Elle indique à Subversion de ne pas libérer les verrous posés sur les fichiers que vous venez de propager. Si cette option est définie à yes, Subversion ne libérera jamais automatiquement les verrous, il vous laissera le soin de lancer explicitement la commande svn unlock. La valeur par défaut est no.

La valeur de cette option est une liste d'extensions de fichiers (séparées par des espaces) que Subversion doit préserver quand il génère des noms de fichiers lors des conflits. Par défaut, cette liste est vide. C'est une nouvelle option apparue dans Subversion 1.5.

Quand Subversion détecte des conflits dans les modifications effectuées sur un fichier, il soumet la résolution de ces conflits à l'utilisateur. Pour aider l'utilisateur à les résoudre, Subversion garde une copie originale des différentes versions en lice du fichier dans la copie de travail. Par défaut, ces fichiers ont des noms construits en ajoutant au nom de fichier original une extension particulière telle que .mine ou .REV (où REV est un numéro de révision). Ceci peut être gênant sur les systèmes d'exploitation qui utilisent les extensions de noms de fichiers pour déterminer l'application par défaut à utiliser pour ouvrir et éditer le fichier, le fichier avec la nouvelle extension n'étant plus automatiquement ouvert dans l'application prévue. Par exemple, si le fichier NotesDeVersion.pdf est en conflit, les fichiers générés risquent de s'appeler NotesDeVersion.pdf.mine ou NotesDeVersion.pdf.r4231. Bien que votre système soit peut-être configuré pour ouvrir les fichiers .pdf avec Acrobat Reader, il n'existe sûrement pas d'application préconfigurée pour ouvrir les fichiers avec l'extension .r4231.

Vous pouvez arranger cela en utilisant cette option de configuration. Pour les fichiers dont l'extension est spécifiée, Subversion ajoutera au nom des fichiers générés l'extension particulière liée au conflit, mais il rajoutera aussi à la suite l'extension originale. Dans l'exemple précédent, en supposant que pdf est une des extensions configurée dans la liste ci-dessus, les noms des fichiers générés pour NotesDeVersion.pdf vont être NotesDeVersion.pdf.mine.pdf et NotesDeVersion.pdf.r4231.pdf. Comme chaque fichier se termine par .pdf, l'application appropriée sera utilisée pour les visualiser.

Normalement, les fichiers de votre copie de travail ont un horodatage qui indique la dernière fois qu'ils ont été modifiés par une action, que ce soit votre éditeur ou une commande svn. C'est généralement le comportement attendu par les développeurs de logiciels, car les chaînes de compilation utilisent souvent ces horodatages pour déterminer quels fichiers ont besoin d'être recompilés.

Toutefois, il existe certaines situations où l'on désire que l'horodatage des fichiers de la copie de travail indique la dernière modification dans le dépôt. La commande svn export fixe toujours l'horodatage sur les arborescences qu'elle produit à l'« horodatage de la dernière propagation ». En configurant cette variable à yes,les commandes svn checkout, svn update, svn switch et svn revert fixeront l'horodatage des fichiers qu'elles modifient à l'horodatage de la dernière propagation.

Cette option active le verrouillage exclusif de SQLite pour le client, ce qui permet d'améliorer les performances dans le cas de copies de travail stockées sur des disques réseaux. En affectant svn à cette variable, vous demandez au client texte interactif de Subversion d'utiliser le verrouillage exclusif. Cela diminue le temps pris par le verrouillage, mais cela signifie qu'un seul client Subversion pourra accéder à la copie de travail à la fois. Un deuxième client qui essaie d'accéder à la copie de travail verrouillée sera bloqué pendant dix secondes puis recevra une erreur. Dans la plupart des cas, le verrouillage partagé est préférable mais si la copie de travail est stockée sur un disque réseau plutôt que sur un disque local, le temps de verrouillage est plus significatif. Lorsque vous travaillez sur de grosses copies de travail sur des disques réseau, le verrouillage exclusif peut apporter une amélioration sensible des performances, en étant jusqu'à deux ou trois fois plus rapide dans certains cas. Cette option est apparue dans Subversion 1.8.

En affectant true à cette variable, vous activez le verrouillage exclusif SQLite des copies de travail pour tous les clients Subversion 1.8. L'activation de cette option peut engendrer des erreurs sur certains clients. La valeur par défaut est false. Cette option est apparue avec Subversion 1.8.

C'est une liste (dont les éléments sont séparés par des points-virgules) de méthodes d'authentification que le client acceptera. Les méthodes valides sont basic, digest et negotiate, sachant que le comportement par défaut est d'accepter n'importe quelle méthode. Un client qui ne veut pas transmettre en clair ses éléments d'authentification peut, par exemple, affecter la valeur digest;negotiate à cette option (et ne mentionnera donc pas basic). Notez que cette option n'est prise en compte que par le module Subversion pour les accès HTTP basé sur la bibliothèque Neon.

Cette option spécifie si Subversion doit envoyer des requêtes réseau compressées vers les serveurs DAV. La valeur par défaut est yes (cependant, la compression ne sera effective que si la couche réseau a été compilée avec le support de la compression). En affectant la valeur no, vous désactivez la compression et vous pourrez alors analyser plus facilement les transmissions réseau.

La variable http-library permet de spécifier (de manière générale ou pour un groupe de serveurs particuliers seulement) lequel des modules d'accès WebDAV vous souhaitez utiliser. Avant la version 1.8, Subversion proposait deux modules : l'implémentation originale libsvn_ra_neon (choisie avec la valeur neon) et la plus récente libsvn_ra_serf (choisie avec la valeur serf). Depuis Subversion 1.8, seule libsvn_ra_serf reste disponible. Cette option reste présente, cependant, car le fichier de configuration se veut aussi indépendant que possible de la version de Subversion. Les utilisateurs qui disposent de plusieurs versions de Subversion installées sur leur système peuvent vouloir utiliser libsvn_ra_neon pour des sites sur lesquels ils se connectent avec de vieilles versions de Subversion.

Cette option contient une liste de motifs (séparés par des virgules) de noms de machines qui doivent être contactées directement, sans passer par le mandataire. La syntaxe des motifs est la même que celle utilisée par le shell Unix pour les noms de fichiers. L'accès aux dépôts d'une machine dont le nom correspond à l'un de ces motifs se fera sans passer par un mandataire.

Cette option contient le nom de la machine mandataire pour les requêtes HTTP de Subversion. La valeur par défaut est vide, ce qui signifie que Subversion ne tentera pas de faire passer ses requêtes par un mandataire mais essaiera de contacter la machine de destination directement.

Cette option spécifie le mot de passe à fournir à la machine mandataire. Par défaut, la valeur est vide.

Cette option contient le numéro du port à utiliser sur la machine mandataire. Par défaut, la valeur est vide.

Cette option spécifie le nom d'utilisateur à fournir à la machine mandataire. Par défaut, la valeur est vide.

Cette option contient la durée maximum, en secondes, pendant laquelle Subversion attend la réponse du serveur. Si vous rencontrez des problèmes d'opérations Subversion qui expirent à cause d'une connexion réseau trop lente, vous devez augmenter cette valeur. Avec Subversion 1.8 (ou des versions plus anciennes utilisant le module HTTP basé sur Serf), utilisez la valeur 0 pour désactiver le délai d'attente maximal.

Spécifier ici un masque binaire sous la forme d'un entier que la bibliothèque HTTP sous-jacente Neon utilise pour définir le type d'affichage de débogage que vous voulez. La valeur par défaut est 0, ce qui n'affiche aucune information de débogage. Avant la version 1.8, la plupart des clients Subversion utilisaient Neon (via le module d'accès au dépôt libsvn_ra_neon) pour les communications WebDAV/HTTP entre le client et le serveur. Le support de libsvn_ra_neon a été enlevé dans Subversion 1.8 ce qui rend cette option obsolète pour les nouvelles installations de Subversion.

Cette option contient une liste de chemins (séparés par des points-virgules) vers les fichiers contenant les certificats des autorités de certifications (abrégé en AC en français et CA en anglais) qui doivent être reconnues comme de confiance par le client Subversion lors des accès aux dépôts en HTTPS.

Si un hôte (ou un ensemble d'hôtes) demande un certificat SSL au client, vous serez invité à fournir le chemin de votre certificat. En affectant un chemin à cette variable, Subversion sera capable de trouver automatiquement votre certificat et ne vous sollicitera pas. Il n'existe pas d'emplacement standard pour stocker un certificat utilisateur sur le disque ; Subversion va le chercher à l'endroit que vous lui spécifiez.

Si votre certificat client SSL est protégé par une phrase de passe, Subversion vous la demandera à chaque fois que le certificat est utilisé. Si vous trouvez cela pénible (et que cela ne vous dérange pas que cette phrase de passe soit stockée dans le fichier servers), vous pouvez affecter la phrase de passe de votre certificat à cette variable. Vous ne serez plus sollicité.

La valeur affectée à cette option est le nom du fournisseur PKCS#11 auquel Subversion demande un certificat client SSL (si le serveur en demande un). Cette option n'est pertinente que pour le module HTTP basé sur Neon, qui a été enlevé de Subversion dans la version 1.8.

Mettez cette variable à yes si vous voulez que Subversion fasse automatiquement confiance à l'ensemble des autorités de certification livrées par défaut avec OpenSSL.

cette option est équivalente à store-passwords sauf qu'elle applique la mise en cache sur le disque (ou non) à l'ensemble des informations d'authentification : identifiants, mots de passe, certificats serveur et tout autre type d'élément pouvant être mis en cache.

Cette option demande à Subversion de garder en cache (ou non) les mots de passe qui sont tapés par l'utilisateur en réponse aux demandes d'authentification des serveurs. La valeur par défaut est yes. Remplacez cette valeur par no pour désactiver la mise en cache sur le disque. Vous pouvez outrepasser cette option pour un appel donné d'une commande svn en utilisant l'option de ligne de commande --no-auth-cache (pour les sous-commandes qui acceptent cette option). Pour plus d'informations, consultez la section intitulée « Mise en cache des éléments d'authentification ». Notez que, indépendamment de la valeur pour cette option, Subversion ne stockera jamais les mots de passe en clair à moins que l'option store-plaintext-passwords ne soit positionnée aussi à yes.

Cette variable n'est important que pour les systèmes de type Unix. Elle contrôle ce que le client Subversion fait lorsque le mot de passe pour le domaine d'authentification en cours ne peut être mis en cache sur le disque que en clair, dans la zone ~/.subversion/auth/. Vous pouvez affecter yes (resp. no) pour autoriser (resp. interdire) la mise en cache des mots de passe en clair. La valeur par défaut est ask, ce qui entraine que le client Subversion vous demande ce qu'il faut faire à chaque fois qu'un nouveau mot de passe doit être ajouté dans la zone de cache ~/.subversion/auth/.

Cette option contrôle si Subversion met en cache les phrases de passe pour les certificats SSL clients de l'utilisateur. La valeur par défaut est yes. Vous pouvez fixer la valeur à no pour interdire la mise en cache des phrases de passe.

Cette variable contrôle si Subversion, au moment de la mise en cache de la phrase de passe d'un certificat SSL client, sera autorisé à le faire en stockant cette information en clair sur le disque. La valeur par défaut est ask, ce qui entraine que le client Subversion vous demande ce qu'il faut faire à chaque fois qu'une nouvelle phrase de passe doit être ajoutée dans la zone de cache ~/.subversion/auth/. Vous pouvez définir la valeur à yes ou no pour indiquer votre préférence et ainsi éviter d'être sollicité à chaque fois.