SVNBOOK Chap3 File Portability
De Framalang Wiki.
Cette section fait partie du livre Version control with subversion
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Hotshot92 | Traduction | Fait | |
| SVF | 1ère Relecture | Fait | |
| Validation |
Sommaire |
File Portability
File Portability
Portabilité des fichiers
Fortunately for Subversion users who routinely find themselves on different computers with different operating systems, Subversion's command-line program behaves almost identically on all those systems. If you know how to wield svn on one platform, you know how to wield it everywhere.
However, the same is not always true of other general classes of software, or of the actual files you keep in Subversion. For example, on a Windows machine, the definition of a “text file” would be similar to that used on a Linux box, but with a key difference—the character sequences used to mark the ends of the lines of those files. There are other differences, too. Unix platforms have (and Subversion supports) symbolic links; Windows does not. Unix platforms use filesystem permission to determine executability; Windows uses filename extensions.
Because Subversion is in no position to unite the whole world in common definitions and implementations of all of these things, the best it can do is to try to help make your life simpler when you need to work with your versioned files and directories on multiple computers and operating systems. This section describes some of the ways Subversion does this.
Heureusement pour les utilisateurs de Subversion qui travaillent sur différents ordinateurs et systèmes d'exploitation, le comportement du programme en ligne de commande est pratiquement identique sur tous les systèmes. Si vous vous débrouillez 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.
File Content Type
File Content Type
Type de contenu des fichiers
Subversion joins the ranks of the many applications which recognize and make use of Multipurpose Internet Mail Extensions (MIME) content types. Besides being a general-purpose storage location for a file's content type, the value of the svn:mime-type file property determines some behavioral characteristics of Subversion itself.
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.
- Various programs on most modern operating systems make assumptions about the type and format of the contents of a file by the file's name, specifically its file extension. For example, files whose names end in .txt are generally assumed to be human-readable, able to be understood by simple perusal rather than requiring complex processing to decipher. Files whose names end in .png, on the other hand, are assumed to be of the Portable Network Graphics type—not human-readable at all, and sensible only when interpreted by software which understands the PNG format and can render the information in that format as a raster image.
- Unfortunately, some of those extensions have changed their meanings over time. When personal computers first appeared, a file named README.DOC would have almost certainly been a plaintext file, just like today's .txt files. But by the mid-1990's, you could almost bet that a file of that name would not be a plaintext file at all, but instead a Microsoft Word document in a proprietary, non-human-readable format. But this change didn't occur overnight—there was certainly a period of confusion for computer users over what exactly they had in hand when they saw a .DOC file. [10]
- The popularity of computer networking cast still more doubt on the mapping between a file's name and its content. With information being served across networks and generated dynamically by server-side scripts, there was often no real file per se, and therefore no file name. Web servers, for example, needed some other way to tell browsers what they were downloading so the browser could do something intelligent with that information, whether that was to display the data using a program registered to handle that data type, or to prompt the user for where on the client machine to store the downloaded data.
- Eventually, a standard emerged for, among other things, describing the contents of a data stream. In 1996, RFC2045 was published, the first of five RFCs describing MIME. It describes the concept of media types and subtypes, and recommends a syntax for the representation of those types. Today, MIME media types—or “MIME types”—are used almost universally across e-mail applications, Web servers, and other software as the de facto mechanism for clearing up the file content confusion.
- Beaucoup de programmes sur les systèmes d'exploitation modernes font des suppositions sur le type et le format du contenu d'un fichier à partir de son nom, notamment son extension. Par exemple, les fichiers qui se terminent par .txt sont généralement considérés comme lisibles par un être humain, aptes à être compris pratiquement tels quels, sans nécessiter un processus de décodage compliqué. Les fichiers dont le nom se termine par .png, en revanche, sont considérés comme des fichiers du type "Portable Network Graphics", illisibles pour un être humain, et utilisables uniquement au travers d'un logiciel qui comprend le format PNG pour pouvoir l'afficher en tant qu'image matricielle.
- Malheureusement, certaines de ces extensions ont changé de sens au fil du temps. Au début des ordinateurs personnels, un fichier LISEZMOI.DOC aurait certainement été un simple fichier texte, comme aujourd'hui les fichiers .txt. Mais, rendu au milieu des années 1990, vous pouvez parier que ce fichier ne serait plus un simple fichier texte, mais un document "Microsoft Word", format propriétaire et illisible pour un être humain. Ce changement n'a pas eu lieu du jour au lendemain et il y a eu une période de confusion pour les utilisateurs qui, lorsqu'ils tombaient sur un fichier .doc, ne savaient pas trop de quel type était ce fichier. [10]
- L'essor des réseaux informatiques n'a fait qu'ajouter à la confusion sur la relation entre le nom d'un fichier et son contenu. Avec l'information circulant à travers les réseaux, souvent générée dynamiquement par des programmes sur les serveurs, il n'y avait plus de fichier en tant que tel, et donc plus de nom de fichier. Les serveurs Web, par exemple, avaient besoin d'un autre moyen pour indiquer au navigateur quel type de contenu il télécharge afin qu'il puisse appliquer un traitement cohérent à cette information : soit afficher les données à l'aide d'un programme qui sait traiter ce type de contenu, soit demander à l'utilisateur où stocker les données téléchargées.
- Finalement, un standard est apparu pour, entre autres, décrire le contenu d'un flux de données. En 1996, on publiait la RFC2045, la première des cinq RFC à décrire le format MIME. Elle décrit le concept de types de média et de sous-types, et recommande une syntaxe pour représenter ces types. Aujourd'hui, les types de média MIME (ou simplement types MIME) sont utilisés de manière pratiquement universelle par les clients de messagerie, les serveurs Web et autres logiciels, pour déterminer de manière sûre le type de contenu d'un fichier.
For example, one of the benefits that Subversion typically provides is contextual, line-based merging of changes received from the server during an update into your working file. But for files containing non-textual data, there is often no concept of a “line”. So, for versioned files whose svn:mime-type property is set to a non-textual MIME type (generally, something that doesn't begin with text/, though there are exceptions), Subversion does not attempt to perform contextual merges during updates. Instead, any time you have locally modified a binary working copy file that is also being updated, your file is left untouched and Subversion creates two new files. One file has a .oldrev extension and contains the BASE revision of the file. The other file has a .newrev extension and contains the contents of the updated revision of the file. This behavior is really for the protection of the user against failed attempts at performing contextual merges on files that simply cannot be contextually merged.
Also, if the svn:mime-type property is set, then the Subversion Apache module will use its value to populate the Content-type: HTTP header when responding to GET requests. This gives your web browser a crucial clue about how to display a file when you use it to peruse your Subversion repository's contents.
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 version 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. A 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.
Par ailleurs, si la propriété svn:mime-type est définie, alors le greffon Apache pour Subversion utilisera cette valeur pour renseigner le champ Content-type: de l'en-tête HTTP en réponse à une requête GET. Cela fournit une indication très importante au navigateur Web pour pouvoir afficher correctement le fichier quand vous l'utilisez pour parcourir le contenu du dépôt Subversion.
File Executability
File Executability
Fichiers exécutables ou non
On many operating systems, the ability to execute a file as a command is governed by the presence of an execute permission bit. This bit usually defaults to being disabled, and must be explicitly enabled by the user for each file that needs it. But it would be a monumental hassle to have to remember exactly which files in freshly checked-out working copy were supposed to have their executable bits toggled on, and then to have to do that toggling. So, Subversion provides the svn:executable property as a way to specify that the executable bit for the file on which that property is set should be enabled, and Subversion honors that request when populating working copies with such files.
This property has no effect on filesystems that have no concept of an executable permission bit, such as FAT32 and NTFS. [11] Also, although it has no defined values, Subversion will force its value to * when setting this property. Finally, this property is valid only on files, not on directories.
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 [11]. Par ailleurs, bien qu'elle n'ait pas de valeurs définies, Subversion lui attribuera la valeur * lorsqu'il activera cette propriété. Enfin, cette propriété n'est valide que sur des fichiers, pas sur des répertoires.
End-of-Line Character Sequences
End-of-Line Character Sequences
Caractères de fin de ligne
Unless otherwise noted using a versioned file's svn:mime-type property, Subversion assumes the file contains human-readable data. Generally speaking, Subversion only uses this knowledge to determine if contextual difference reports for that file are possible. Otherwise, to Subversion, bytes are bytes.
This means that by default, Subversion doesn't pay any attention to the type of end-of-line (EOL) markers used in your files. Unfortunately, different operating systems have different conventions about which character sequences represent the end of a line of text in a file. For example, the usual line ending token used by software on the Windows platform is a pair of ASCII control characters—a carriage return (CR) followed by a line feed (LF). Unix software, however, just uses the LF character to denote the end of a line.
Not all of the various tools on these operating systems understand files that contain line endings in a format that differs from the native line ending style of the operating system on which they are running. So, typically, Unix programs treat the CR character present in Windows files as a regular character (usually rendered as ^M), and Windows programs combine all of the lines of a Unix file into one giant line because no carriage return-linefeed (or CRLF) character combination was found to denote the ends of the lines.
This sensitivity to foreign EOL markers can be frustrating for folks who share a file across different operating systems. For example, consider a source code file, and developers that edit this file on both Windows and Unix systems. If all the developers always use tools which preserve the line ending style of the file, no problems occur.
But in practice, many common tools either fail to properly read a file with foreign EOL markers, or they convert the file's line endings to the native style when the file is saved. If the former is true for a developer, he has to use an external conversion utility (such as dos2unix or its companion, unix2dos) to prepare the file for editing. The latter case requires no extra preparation. But both cases result in a file that differs from the original quite literally on every line! Prior to committing his changes, the user has two choices. Either he can use a conversion utility to restore the modified file to the same line ending style that it was in before his edits were made. Or, he can simply commit the file—new EOL markers and all.
The result of scenarios like these include wasted time and unnecessary modifications to committed files. Wasted time is painful enough. But when commits change every line in a file, this complicates the job of determining which of those lines were changed in a non-trivial way. Where was that bug really fixed? On what line was a syntax error introduced?
The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are:
Sur un fichier suivi en version, Subversion considère que le contenu est lisible par un humain, à moins que la propriété svn:mime-type n'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 les fins de ligne. 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 signifier les fins de lignes.
Tous les logiciels sur ces plates-formes ne reconnaissent pas forcément les fichiers qui contiennent des fins de lignes codées d'une autre manière que la manière standard sur leur plate-forme. Ainsi, typiquement, les programmes Unix traitent le caractère CR des fichiers Windows comme un caractère normal (et affichent généralement ^M) ; et les programmes Windows concatènent toutes les lignes d'un fichier Unix dans une unique ligne géante car la combinaison retour chariot-saut de ligne (CRLF) n'apparaît nulle part dans le fichier.
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 dans le 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. A 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
- This causes the file to contain the EOL markers that are native to the operating system on which Subversion was run. In other words, if a user on a Windows machine checks out a working copy that contains a file with an svn:eol-style property set to native, that file will contain CRLF EOL markers. A Unix user checking out a working copy which contains the same file will see LF EOL markers in his copy of the file.
- Note that Subversion will actually store the file in the repository using normalized LF EOL markers regardless of the operating system. This is basically transparent to the user, though.
- 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 stockera 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
- This causes the file to contain CRLF sequences for EOL markers, regardless of the operating system in use.
- CRLF
- Le fichier contiendra le marqueur CRLF pour indiquer les fins de ligne, quel que soit le système d'exploitation.
- LF
- This causes the file to contain LF characters for EOL markers, regardless of the operating system in use.
- LF
- Le fichier contiendra le marqueur LF pour indiquer les fins de ligne, quel que soit le système d'exploitation.
- CR
- This causes the file to contain CR characters for EOL markers, regardless of the operating system in use. This line ending style is not very common. It was used on older Macintosh platforms (on which Subversion doesn't even run).
- CR
- Le fichier contiendra le marqueur CR pour indiquer les fins de ligne, quel que soit le système d'exploitaton. Ce marqueur de fin de ligne n'est pas très courant. Il était utilisé sur les vieux Macintosh (machines sur lesquelles Subversion ne tourne même pas).
