This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.

Portabilité des fichiers

Heureusement pour les utilisateurs de Subversion qui travaillent sur différents ordinateurs et systèmes d'exploitation, le comportement du client texte interactif est pratiquement identique sur tous les systèmes. Si vous vous débrouillez avec svn sur un système, vous devriez vous en sortir sur n'importe quel système.

Cependant, ce n'est pas toujours le cas pour d'autres types de logiciels ou pour les fichiers que vous gérez dans Subversion. Par exemple, sur un système Windows, la définition d'un « fichier texte » est similaire à la définition de Linux, mais avec une différence notable pour ce qui concerne les retours à la ligne. Il y a aussi d'autres différences. Les plateformes Unix (et Subversion) supportent la notion de lien symbolique ; Windows non. Les plateformes Unix utilisent les permissions du fichier pour déterminer si un fichier est exécutable ; Windows utilise l'extension du fichier.

Subversion n'a pas la possibilité d'unifier toutes ces définitions et ces implémentations. Tout ce qu'il peut faire, c'est aider au maximum l'utilisateur qui travaille sur plusieurs systèmes et plusieurs ordinateurs. Cette section décrit comment Subversion s'y prend.

Type de contenu des fichiers

Subversion fait partie des nombreuses applications qui reconnaissent et utilisent les types MIME (Multipurpose Internet Mail Extensions). Ainsi, la valeur de la propriété svn:mime-type permet, en plus de stocker le type de contenu d'un fichier, de changer le comportement de Subversion lui-même.

Par exemple, un avantage fourni par cette reconnaissance de type par Subversion est la possibilité de fusion contextuelle, ligne par ligne, des changements reçus lors d'une mise à jour. En revanche, pour les fichiers contenant autre chose que du texte, il n'y a souvent pas de concept de « ligne ». En conséquence, pour les fichiers suivis en versions dont la propriété svn:mime-type contient une valeur de type MIME non textuel (généralement un intitulé qui ne commence pas par text/, bien qu'il y ait des exceptions), Subversion ne tente pas de fusion contextuelle pendant la mise à jour. À la place, chaque fois que vous avez modifié localement un fichier binaire qui a été mis à jour sur le dépôt, Subversion ne touche pas à votre fichier mais crée deux nouveaux fichiers. Un fichier avec l'extension .oldrev qui contient la version du fichier à la révision BASE. Un autre fichier avec l'extension .newrev qui contient la version à jour du fichier. Ce comportement est dicté par la volonté d'éviter que l'utilisateur ne tente d'effectuer une fusion qui échouerait parce que les fichiers ne peuvent tout simplement pas être fusionnés.

De plus, puisque le fait d'afficher les différences et les modifications ligne par ligne est, c'est évident, dépendant de la signification que l'on accorde à une « ligne » du fichier considéré, les fichiers dont le type MIME n'est pas compatible avec du texte déclencheront par défaut des erreurs lorsqu'ils sont la cible de sous-commandes telles que svn diff et svn annotate. Cela peut s'avérer particulièrement frustrant pour les utilisateurs de fichiers XML dont la propriété svn:mime-type est définie avec une valeur comme application/xml qui n'est pas interprétée par Subversion comme lisible par un humain car relativement ambigüe. Heureusement, ces sous-commandes proposent l'option --force pour obliger Subversion à essayer d'opérer sur ces fichiers malgré leur apparente illisibilité pour un humain.

[Avertissement] Avertissement

La propriété svn:mime-type, lorsqu'elle est définie avec une valeur qui n'indique pas de contenu textuel, peut entrainer des comportements inattendus avec les autres propriétés. Par exemple, comme la notion de fin de ligne (et donc de conversion de caractère de fin de ligne) n'a pas de sens pour un fichier binaire, Subversion vous empêche de définir la propriété svn:eol-style sur ces fichiers. Cela saute aux yeux lorsque vous travaillez sur un seul fichier et que svn propset génère une erreur. C'est beaucoup moins évident si vous effectuez une opération récursive, où Subversion omet silencieusement les fichiers qu'il considère inappropriés pour une propriété donnée.

Subversion fournit plusieurs mécanismes pour définir automatiquement la propriété svn:mime-type sur un fichier suivi en versions. Consultez la section intitulée « Configuration automatique des propriétés » pour en obtenir les détails.

Par ailleurs, si la propriété svn:mime-type est définie, alors le greffon Apache pour Subversion utilise cette valeur pour renseigner le champ Content-type: de l'en-tête HTTP en réponse à une requête GET. Cela fournit au navigateur Web une indication très importante pour pouvoir afficher correctement le fichier, quand vous l'utilisez pour parcourir le contenu du dépôt Subversion.

Fichiers exécutables ou non

Sur beaucoup de systèmes d'exploitation, la capacité de rendre un fichier exécutable dépend d'un bit dit « exécutable ». Habituellement, ce bit est désactivé par défaut et doit être explicitement activé par l'utilisateur pour chaque fichier concerné. Ce serait une perte de temps énorme d'avoir à se rappeler exactement quel fichier, parmi ceux que l'on vient d'extraire du dépôt, doit avoir le bit exécutable positionné et ensuite de devoir le faire manuellement. C'est pourquoi Subversion fournit la propriété svn:executable pour spécifier que le bit exécutable doit être activé pour le fichier concerné. Subversion s'occupe lui-même de cette tâche quand il rapatrie de tels fichiers dans la copie de travail locale.

Cette propriété n'a aucun effet sur les systèmes de fichiers qui ne possèdent pas le concept du bit exécutable, tels que FAT32 et NTFS [20]. Par ailleurs, bien qu'elle n'ait pas de valeurs définies, Subversion lui attribue la valeur * lorsqu'il active cette propriété. Enfin, cette propriété n'est valide que sur des fichiers, pas sur des dossiers.

Caractères de fin de ligne

Pour tout fichier suivi en versions, Subversion considère que le contenu est lisible par un humain sauf si la propriété svn:mime-type indique le contraire. En règle générale, Subversion utilise cette information pour déterminer s'il est possible d'effectuer une comparaison contextuelle pour ce fichier. Sinon, pour Subversion, les octets sont des octets.

Cela veut dire que par défaut, Subversion ne s'intéresse pas au type de caractère utilisé pour marquer les fins de lignes (EOL en anglais, pour End Of Line). Malheureusement, des conventions différentes sont utilisées suivant les systèmes d'exploitation pour indiquer une fin de ligne de texte dans un fichier. Par exemple, les logiciels sous Windows utilisent généralement une paire de caractères de contrôle ASCII : un retour chariot (CR, carriage return) suivi par un saut de ligne (LF, line feed). Les logiciels Unix, cependant, utilisent uniquement le caractère LF pour indiquer les fins de lignes.

Tous les programmes ne savent pas gérer les fichiers utilisant un marqueur de fin de ligne « exogène » au système d'exploitation sur lequel ils tournent. Ainsi, il n'est pas rare de voir les programmes Unix traiter le marqueur CR des fichiers Windows comme un caractère normal (en affichant à l'écran un ^M) et les programmes Windows combiner en une seule ligne immense un fichier Unix parce qu'ils n'y ont pas trouvé la combinaison retour chariot-passage à la ligne (CR-LF).

Cette incapacité de traiter correctement les marqueurs de fin de ligne d'autres plates-formes peut être assez frustrante pour ceux qui partagent des fichiers entre différents systèmes d'exploitation. Prenons l'exemple d'un fichier de code source qui est édité par des développeurs à la fois sous Windows et sous Unix. Si tous les développeurs utilisent des outils qui se plient à la convention utilisée par le fichier, pas de problème.

Mais, en pratique, de nombreux outils largement utilisés soit ne parviennent pas à lire correctement un fichier utilisant une convention différente pour les fins de ligne, soit ils convertissent les fins de lignes au format local lors de la sauvegarde. Dans le premier cas, le développeur doit utiliser des outils externes (tels que dos2unix et son compagnon unix2dos) pour préparer le fichier avant l'édition. Dans le deuxième cas, pas besoin de préparation. Mais dans les deux cas, le fichier résultant diffère de l'original littéralement pour toutes les lignes ! Avant de propager ses changements, l'utilisateur a deux choix. Soit il utilise un utilitaire de conversion pour revenir à la même convention qu'avant l'édition. Soit il propage le fichier avec la nouvelle convention de fin de ligne.

Au final, les deux hypothèses conduisent à une perte de temps et des modifications inutiles sur les fichiers propagés. La perte de temps est déjà pénible. Mais si en plus la propagation change chaque ligne du fichier, trouver quelle ligne a effectivement changé devient non trivial. À quel endroit ce bogue a-t-il réellement été corrigé ? Dans quelle ligne y avait-il cette erreur de syntaxe ?

La solution à ce problème est la propriété svn:eol-style (eol pour End Of Line). Quand cette propriété possède une valeur valide, Subversion l'utilise pour déterminer quel traitement il doit appliquer pour que le fichier ne change pas de convention à chaque propagation provenant d'un système d'exploitation différent. Les valeurs valides sont :

native

Ceci force le fichier à adopter la convention utilisée par le système d'exploitation sur lequel s'exécute Subversion. En d'autres termes, si un utilisateur d'une machine Windows récupère une copie de travail d'un fichier dont la propriété svn:eol-style vaut native, ce fichier contiendra le marqueur CRLF pour indiquer les fins de ligne. Un utilisateur Unix qui récupère une copie de travail qui contient le même fichier verra simplement LF pour indiquer les fins de ligne sur sa copie.

Notez que Subversion stocke en fait le fichier dans le dépôt en utilisant le marqueur standard LF indépendamment du système d'exploitation. Cela reste toutefois tout à fait transparent pour l'utilisateur.

CRLF

Le fichier contiendra le marqueur CRLF pour indiquer les fins de ligne, quel que soit le système d'exploitation..

LF

Le fichier contiendra le marqueur LF pour indiquer les fins de ligne, quel que soit le système d'exploitation.

CR

Le fichier contiendra le marqueur CR pour indiquer les fins de ligne, quel que soit le système d'exploitation. Ce marqueur de fin de ligne n'est pas très courant.



[19] Ca vous semble dur ? Et bien, à la même période, WordPerfect utilisait aussi .DOC comme extension préférée de son format de fichier propriétaire !

[20] Les systèmes de fichiers Windows utilisent les extensions des fichiers (telles que .EXE, .BAT et .COM) pour indiquer que les fichiers sont exécutables.