SVNBOOK Chap3 Ignoring Unversioned Items
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 |
Ignoring Unversioned Items
Ignoring Unversioned Items
Ignorer les éléments non-versionnés
In any given working copy there is a good chance that alongside all those versioned files and directories are other files and directories which are neither versioned nor intended to be. Text editors litter directories with backup files. Software compilers generate intermediate—or even final—files which you typically wouldn't bother to version. And users themselves drop various other files and directories wherever they see fit, often in version control working copies.
It's ludicrous to expect Subversion working copies to be somehow impervious to this kind of clutter and impurity. In fact, Subversion counts it as a feature that its working copies are just typical directories, just like unversioned trees. But these not-to-be-versioned files and directories can cause some annoyance for Subversion users. For example, because the svn add and svn import commands act recursively by default, and don't know which files in a given tree you do and don't wish to version, it's easy to accidentally add stuff to version control that you didn't mean to. And because svn status reports, by default, every item of interest in a working copy—including unversioned files and directories—its output can get quite noisy where many of these things exist.
So Subversion provides two ways for telling it which files you would prefer that it simply disregard. One of the ways involves the use of Subversion's runtime configuration system (see the section called “Runtime Configuration Area”), and therefore applies to all the Subversion operations which make use of that runtime configuration, generally those performed on a particular computer, or by a particular user of a computer. The other way makes use of Subversion's directory property support, is more tightly bound to the versioned tree itself, and therefore affects everyone who has a working copy of that tree. Both of the mechanisms use file patterns.
Dans n'importe quelle copie de travail, il y a de grandes chances que les fichiers et répertoires suivis en version côtoient d'autres fichiers et répertoires non suivis en version ou qui n'ont pas lieu de l'être. Les éditeurs de texte remplissent les répertoires avec des fichiers de sauvegarde. Les compilateurs créent des fichiers intermédiaires (ou même des fichiers finaux) que vous ne voudrez pas suivre en version. Et les utilisateurs eux-mêmes déposent des fichiers et des répertoires où bon leur semble, souvent dans des copies de travail locales.
Il est ridicule de penser que les copies de travail Subversion échappent à ce type de méli-mélo. En fait, Subversion prend en compte dès le début que les copies de travail sont des répertoires comme les autres, comme ceux qui ne sont pas suivis en version. Mais ces fichiers et répertoires qui-n-ont-pas-vocation-à-être-suivis-en-version peuvent perturber les utilisateurs de Subversion. Par exemple, comme les commandes svn add et svn import sont récursives par défaut, et ne savent pas quels fichiers de l'arborescence vous voulez suivre ou non en version, il est relativement facile d'ajouter au suivi de versions des éléments que vous ne vouliez pas suivre. Et comme la commande svn status traite, par défaut, tous les éléments intéressants dans la copie de travail, y compris les fichiers et répertoires non suivis en version, son affichage devient rapidement confus avec de tels imbroglios.
C'est pourquoi Subversion fournit deux façons de lui indiquer quels fichiers vous souhaitez ignorer. La première implique l'utilisation de l'a zone de configuration exécutable (voir la section "Zone de configuration exécutable"), et par conséquent s'applique à toutes les opérations Subversion qui utilisent cette zone de configuration, généralement toutes celles de l'ordinateur ou d'un utilisateur particulier de l'ordinateur. L'autre façon utilise les propriétés Subversion des répertoires et est plus liée à l'arborescence suivie en version elle-même. Par conséquent, elle affecte tous ceux qui possèdent une copie de travail de cette arborescence. Les deux mécanismes utilisent des motifs de noms de fichiers.
The Subversion runtime configuration system provides an option, global-ignores, whose value is a whitespace-delimited collection of file patterns (also known as globs). The Subversion client checks these patterns against the names of the files which are candidates for addition to version control, as well as to unversioned files which the svn status command notices. If any file's name matches one of the patterns, Subversion will basically act as if the file didn't exist at all. This is really useful for the kinds of files that you almost never want to version, such as editor backup files like Emacs' *~ and .*~ files.
La zone de configuration exécutable de Subversion propose une option, global-ignores, dont la valeur est un ensemble de motifs de noms fichiers (appelés aussi globs) séparés par des espaces. Le client Subversion compare ces motifs avec les noms de fichiers que l'on tente d'ajouter au suivi de version, ainsi qu'aux fichiers non suivis en version détectés par la commande svn status. Si un nom de fichier correspond au motif, Subversion ignore totalement ce fichier. C'est particulièrement utile pour les fichiers que vous ne voulez jamais suivre en version, comme les fichiers de sauvegarde créés par les éditeurs de texte (par exemple, les fichiers *~ et .*~ créés d'Emacs).
NOTE : File Patterns in Subversion
- File Patterns in Subversion
- Les motifs de fichier dans Subversion
- File patterns (also called globs or shell wildcard patterns) are strings of characters that are intended to be matched against filenames, typically for the purpose of quickly selecting some subset of similar files from a larger grouping without having to explicitly name each file. The patterns contain two types of characters: regular characters, which are compared explicitly against potential matches, and special wildcard characters, which are interpreted differently for matching purposes.
- There are different types of file pattern syntaxes, but Subversion uses the one most commonly found in Unix systems implemented as the fnmatch system function. It supports the following wildcards, described here simply for your convenience:
- ?
- Matches any single character
- *
- Matches any string of characters, including the empty string
- [
- Begins a character class definition terminated by ], used for matching a subset of characters
- ?
- You can see this same pattern matching behavior at a Unix shell prompt. The following are some examples of patterns being used for various things:
$ ls ### the book sources appa-quickstart.xml ch06-server-configuration.xml appb-svn-for-cvs-users.xml ch07-customizing-svn.xml appc-webdav.xml ch08-embedding-svn.xml book.xml ch09-reference.xml ch00-preface.xml ch10-world-peace-thru-svn.xml ch01-fundamental-concepts.xml copyright.xml ch02-basic-usage.xml foreword.xml ch03-advanced-topics.xml images/ ch04-branching-and-merging.xml index.xml ch05-repository-admin.xml styles.css $ ls ch* ### the book chapters ch00-preface.xml ch06-server-configuration.xml ch01-fundamental-concepts.xml ch07-customizing-svn.xml ch02-basic-usage.xml ch08-embedding-svn.xml ch03-advanced-topics.xml ch09-reference.xml ch04-branching-and-merging.xml ch10-world-peace-thru-svn.xml ch05-repository-admin.xml $ ls ch?0-* ### the book chapters whose numbers end in zero ch00-preface.xml ch10-world-peace-thru-svn.xml $ ls ch0[3578]-* ### the book chapters that Mike is responsible for ch03-advanced-topics.xml ch07-customizing-svn.xml ch05-repository-admin.xml ch08-embedding-svn.xml $
- File pattern matching is a bit more complex than what we've described here, but this basic usage level tends to suit the majority of Subversion users.
- Les motifs de noms de fichiers (également appelés globs ou motifs de filtrages du shell) sont des chaînes de caractères qui sont destinés à être comparés à des noms de fichiers, en général dans le but de sélectionner rapidement un sous-ensemble de fichiers similaires au sein d'un ensemble plus large, sans avoir à nommer explicitement chaque fichier. Les motifs contiennent deux types de caractères : les caractères standard, qui sont comparés explicitement aux noms de fichiers, et les caractères spéciaux (aussi nommés quantificateurs), qui sont interprétés différemment.
- Il y a différents types de syntaxes de motifs, mais Subversion utilise celle qui est la plus répandue sur les systèmes Unix, implémentée dans la fonction fnmatch. Elle reconnaît les caractères spéciaux suivants, décrits ici à titre d'information :
- ?
- Correspond à n'importe quel caractère unique
- *
- Correspond à n'importe quelle chaîne de caractères, y compris la chaîne vide
- [
- Marque le début de la définition d'une classe de caractères, se terminant par ], utilisée pour décrire un sous-ensemble de caractères
- ?
- Vous pouvez observer ce même filtrage de motifs à l'invite de commandes d'un shell Unix. Voici ci-dessous des exemples de motifs utilisés pour différentes choses :
$ ls ### les sources du livre appa-quickstart.xml ch06-server-configuration.xml appb-svn-for-cvs-users.xml ch07-customizing-svn.xml appc-webdav.xml ch08-embedding-svn.xml book.xml ch09-reference.xml ch00-preface.xml ch10-world-peace-thru-svn.xml ch01-fundamental-concepts.xml copyright.xml ch02-basic-usage.xml foreword.xml ch03-advanced-topics.xml images/ ch04-branching-and-merging.xml index.xml ch05-repository-admin.xml styles.css $ ls ch* ### les chapitres du livre ch00-preface.xml ch06-server-configuration.xml ch01-fundamental-concepts.xml ch07-customizing-svn.xml ch02-basic-usage.xml ch08-embedding-svn.xml ch03-advanced-topics.xml ch09-reference.xml ch04-branching-and-merging.xml ch10-world-peace-thru-svn.xml ch05-repository-admin.xml $ ls ch?0-* ### les chapitres du livre dont le numéro se termine par 0 ch00-preface.xml ch10-world-peace-thru-svn.xml $ ls ch0[3578]-* ### les chapitres du livre dont Mike est responsable ch03-advanced-topics.xml ch07-customizing-svn.xml ch05-repository-admin.xml ch08-embedding-svn.xml $
- Le filtrage par motif de fichiers est un peu plus complexe que ce que nous avons décrit ici, mais ce niveau d'utilisation semble suffire à la majorité des utilisateurs de Subversion.
When found on a versioned directory, the svn:ignore property is expected to contain a list of newline-delimited file patterns which Subversion should use to determine ignorable objects in that same directory. These patterns do not override those found in the global-ignores runtime configuration option, but are instead appended to that list. And it's worth noting again that, unlike the global-ignores option, the patterns found in the svn:ignore property apply only to the directory on which that property is set, and not to any of its subdirectories. The svn:ignore property is a good way to tell Subversion to ignore files that are likely to be present in every user's working copy of that directory, such as compiler output or—to use an example more appropriate to this book—the HTML, PDF, or PostScript files generated as the result of a conversion of some source DocBook XML files to a more legible output format.
Pour un répertoire suivi en version, la propriété svn:ignore est supposée contenir une liste de motifs de noms de fichiers (un motif par ligne) que Subversion utilise pour déterminer quels objets ignorer dans le présent répertoire. Ces motifs ne remplacent pas les motifs inscrits dans la directive global-ignores de la zone de configuration exécutable, mais s'ajoutent à cette liste. Veuillez également noter que, contrairement à la directive global-ignores, les motifs de la propriété svn:ignore s'appliquent uniquement au répertoire pour lequel la propriété est définie, et pas à ses sous-répertoires. La propriété svn:ignore est utile pour indiquer à Subversion d'ignorer les fichiers susceptibles d'être présents dans la copie de travail de ce répertoire chez chaque utilisateur comme par exemple les fichiers produits par les compilateurs ou, pour citer un exemple plus approprié à ce livre, les fichiers HTML, PDF ou PostScript générés par la conversion des fichiers sources DocBook XML vers un format de fichier plus lisible.
NOTE
- Subversion's support for ignorable file patterns extends only to the one-time process of adding unversioned files and directories to version control. Once an object is under Subversion's control, the ignore pattern mechanisms no longer apply to it. In other words, don't expect Subversion to avoid committing changes you've made to a versioned file simply because that file's name matches an ignore pattern—Subversion always notices all of its versioned objects.
- Le support des motifs de fichiers à ignorer dans Subversion s'applique uniquement à la procédure d'ajout de fichiers et répertoires non suivis en version vers la gestion de version. Une fois que l'objet est géré en version par Subversion, les mécanismes permettant d'ignorer certains fichiers selon des motifs prédéfinis ne s'applique plus. Autrement dit, ne pensez pas que Subversion ne propagera pas les changements que vous avez faits à un fichier suivi en version simplement parce que son nom correspond à un motif à ignorer : Subversion prend toujours en compte l'ensemble des objets qu'il gère.
NOTE : Ignore Patterns for CVS Users
- Ignore Patterns for CVS Users
- Motifs de fichier à ignorer pour les utilisateurs de CVS
- The Subversion svn:ignore property is very similar in syntax and function to the CVS .cvsignore file. In fact, if you are migrating a CVS working copy to Subversion, you can directly migrate the ignore patterns by using the .cvsignore file as input file to the svn propset command:
$ svn propset svn:ignore -F .cvsignore . property 'svn:ignore' set on '.' $
- La syntaxe et le fonctionnement de la propriété svn:ignore de Subversion sont très similaires au fichier .cvsignore de CVS. Si vous migrez une copie de travail CVS vers Subversion, vous pouvez migrer directement les motifs à ignorer en utilisant le fichier .cvsignore comme entrée à la commande svn propset :
$ svn propset svn:ignore -F .cvsignore . property 'svn:ignore' set on '.' $
- There are, however, some differences in the ways that CVS and Subversion handle ignore patterns. The two systems use the ignore patterns at some different times, and there are slight discrepancies in what the ignore patterns apply to. Also, Subversion does not recognize the use of the ! pattern as a reset back to having no ignore patterns at all.
- Il y a quand même quelques différences entre CVS et Subversion concernant les motifs à ignorer. Les deux systèmes n'utilisent pas les motifs au même moment, et il y a quelques divergences légères sur ce sur quoi ils s'appliquent. D'ailleurs, Subversion ne reconnaît pas le motif ! pour revenir à une situation où aucun motif n'est ignoré.
The global list of ignore patterns tends to be more a matter of personal taste, and tied more closely to a user's particular tool chain than to the details of any particular working copy's needs. So, the rest of this section will focus on the svn:ignore property and its uses.
La liste globale des motifs à ignorer est une affaire de goût, devant plus s'intégrer à la collection d'outils d'un utilisateur particulier que répondre aux besoins d'une copie de travail particulière. C'est pourquoi le reste de cette section s'attachera à décrire l'utilisation de la propriété svn:ignore.
Say you have the following output from svn status:
$ svn status calc M calc/button.c ? calc/calculator ? calc/data.c ? calc/debug_log ? calc/debug_log.1 ? calc/debug_log.2.gz ? calc/debug_log.3.gz
In this example, you have made some property modifications to button.c, but in your working copy you also have some unversioned files: the latest calculator program that you've compiled from your source code, a source file named data.c, and a set of debugging output log files. Now, you know that your build system always results in the calculator program being generated. [12] And you know that your test suite always leaves those debugging log files lying around. These facts are true for all working copies of this project, not just your own. And you know that you aren't interested in seeing those things every time you run svn status, and pretty sure that nobody else is interested in them either. So you use svn propedit svn:ignore calc to add some ignore patterns to the calc directory. For example, you might add this as the new value of the svn:ignore property:
calculator debug_log*
Prenons par exemple le résultat suivant de la commande svn status :
$ svn status calc M calc/bouton.c ? calc/calculatrice ? calc/donnees.c ? calc/debug_log ? calc/debug_log.1 ? calc/debug_log.2.gz ? calc/debug_log.3.gz
Dans cet exemple, des modifications ont été faites sur les propriétés de bouton.c, et il y a aussi des fichiers non suivis en version : le programme calculatrice (résultat de votre dernière compilation du code source), un fichier source donnees.c et un ensemble de fichiers de traces pour le débogage. Vous êtes conscient du fait que compiler votre code engendre à chaque fois la création du programme calculatrice [12]. Vous savez également que vous aurez toujours des fichiers de traces qui traîneront. On peut faire ce constat pour toutes les copies de travail locales de ce projet, pas seulement la vôtre. Et vous savez que cela ne vous intéresse pas, et que cela n'intéresse très probablement aucun autre développeur, de voir ces fichiers apparaître à chaque commande svn status. Vous allez donc utiliser svn propedit svn:ignore calc pour ajouter des motifs à ignorer pour le répertoire calc. Par exemple, vous pourriez ajouter ce qui suit comme nouvelle valeur de la propriété svn:ignore :
calculatrice debug_log*
After you've added this property, you will now have a local property modification on the calc directory. But notice what else is different about your svn status output:
$ svn status M calc M calc/button.c ? calc/data.c
Now, all that cruft is missing from the output! Of course, your calculator compiled program and all those logfiles are still in your working copy. Subversion is simply not reminding you that they are present and unversioned. And now with all the uninteresting noise removed from the display, you are left with more interesting items—such as that source code file data.c that you probably forgot to add to version control.
Of course, this less-verbose report of your working copy status isn't the only one available. If you actually want to see the ignored files as part of the status report, you can pass the --no-ignore option to Subversion:
$ svn status --no-ignore M calc M calc/button.c I calc/calculator ? calc/data.c I calc/debug_log I calc/debug_log.1 I calc/debug_log.2.gz I calc/debug_log.3.gz
As mentioned earlier, the list of file patterns to ignore is also used by svn add and svn import. Both of these operations involve asking Subversion to begin managing some set of files and directories. Rather than force the user to pick and choose which files in a tree she wishes to start versioning, Subversion uses the ignore patterns—both the global and the per-directory lists—to determine which files should not be swept into the version control system as part of a larger recursive addition or import operation. And here again, you can use the --no-ignore option to tell Subversion ignore its ignores list and operate on all the files and directories present.
Après avoir ajouté cette propriété, vous aurez une propriété modifiée localement dans votre répertoire calc. Mais notez les autres différences sur le résultat de la commande svn status :
$ svn status M calc M calc/bouton.c ? calc/donnees.c
Maintenant, tout le superflu a disparu ! Bien sûr, votre programme compilé et les fichiers de trace sont toujours présents dans votre copie locale. Subversion ne vous présente pas ces fichiers présents mais non suivis en version, c'est tout. Et maintenant que ces parasites sont supprimés de l'affichage, il ne vous reste plus que les éléments intéressants, tels que le fichier de code source donnees.c que vous avez probablement oublié d'ajouter au suivi de version.
Bien évidemment, ce compte-rendu plus succinct de l'état de votre copie de travail locale n'est pas le seul possible. Si vous voulez voir les fichiers ignorés dans le compte-rendu, vous pouvez ajouter l'option --no-ignore à la commande Subversion :
$ svn status --no-ignore M calc M calc/bouton.c I calc/calculatrice ? calc/donnees.c I calc/debug_log I calc/debug_log.1 I calc/debug_log.2.gz I calc/debug_log.3.gz
Comme mentionné auparavant, la liste des motifs de fichiers à ignorer est aussi utilisée par svn add et svn import. Ces deux opérations demandent à Subversion de gérer un ensemble de fichiers et de répertoires. Plutôt que de forcer l'utilisateur à choisir quels fichiers dans l'arborescence il souhaite suivre en version, Subversion utilise les motifs de fichiers à ignorer, à la fois la liste globale et ceux définis par répertoire, pour déterminer quels fichiers suivre (ou ne pas suivre) en version dans sa procédure récursive d'ajout ou d'import. Là encore, vous pouvez utiliser l'option --no-ignore pour indiquer à Subversion d'ignorer ces listes et de d'agir effectivement sur tous les fichiers et répertoires présents.
TIP
- Even if svn:ignore is set, you may run into problems if you use shell wildcards in a command. Shell wildcards are expanded into an explicit list of targets before Subversion operates on them, so running svn SUBCOMMAND * is just like running svn SUBCOMMAND file1 file2 file3 …. In the case of the svn add command, this has an effect similar to passing the --no-ignore option. So instead of using a wildcard, use svn add --force . to do a bulk scheduling of unversioned things for addition. The explicit target will ensure that the current directory isn't overlooked because of being already under version control, and the --force option will cause Subversion to crawl through that directory, adding unversioned files while still honoring the svn:ignore property and global-ignores runtime configuration variable. Be sure to also provide the --depth files option to the svn add command if you don't want a fully recursive crawl for things to add.
- Même si svn:ignore est défini, vous risquer de rencontrer des problèmes si vous utilisez des caractères spéciaux du shell dans une commande. Les caractères spéciaux sont remplacés par une liste explicite de cibles avant que Subversion n'agisse sur eux, et donc lancer svn SOUS-COMMANDE * revient à lancer sv SOUS-COMMANDE fichier1 fichier2 fichier3... Dans le cas de la commande svn add, ceci a un effet similaire à l'option --no-ignore. Par conséquent, au lieu d'utiliser un caractère spécial, utilisez plutôt svn add --force . pour marquer d'un seul coup les éléments non-versionnés pour ajout. La cible explicite permet de s'assurer que le répertoire en cours ne sera pas négligé car déjà versionné et l'option --force forcera Subversion à parcourir ce répertoire, ajoutant les fichiers non-versionnés tout en respectant la propriété svn:ignore et la variable global-ignores de la zone de configuration. Pensez à rajouter l'option --depth files à la commande svn add si vous ne voulez pas que la recherche de fichiers à ajouter au suivi de versions ne parcoure le répertoire de façon récursive.
