SVNBOOK Chap1 Subversion in Action Mixed Revision Working Copies
Un article de Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Penguin | Traduction | Terminé | |
| Relecture | |||
| Validation |
Sommaire |
[modifier] Titre
Mixed Revision Working Copies
Copies de Travail avec Révisions Mélangées
[modifier] Paragraphe 1
As a general principle, Subversion tries to be as flexible as possible. One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Unfortunately, this flexibility tends to confuse a number of new users. If the earlier example showing mixed revisions perplexed you, here's a primer on both why the feature exists and how to make use of it.
Un principe général de Subversion est d'être aussi flexible que possible. Une sorte particulière de flexibilité est la capacité d'avoir une copie de travail contenant des fichiers et des répertoires avec un mélange de différents numéros de révision. Malheureusement, cette flexibilité à tendance à embrouiller de nombreux nouveaux utilisateurs. Si les exemples précédents de révisions mélangées vous laissent perplexes, voici une amorce d'explication à la fois sur les raisons pour lesquelles cette fonctionnalité existe, mais aussi sur la façon de l'utiliser.
[modifier] Paragraphe 2
Updates and Commits are Separate
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull”, nor the other way around. Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people. And if you have new changes still in progress, then svn update should gracefully merge repository changes into your own, rather than forcing you to publish them.Mises à jour et Livraisons sont Séparées
Une des règles fondamentales de Subversion est que l'action de "pousser" ne déclenche pas une action de "tirer", ni l'inverse. Le simple fait que vous soyez prêt à soumettre vos nouvelles modifications au dépôt ne veut pas dire que vous êtes prêts à recevoir les modifications d'autres personnes. Et si vous avez encore de nouvelles modifications en cours, alors svn update va gracieusement fusionner les changements du dépôt avec les votres, plutôt que de vous forcer à les publier.[modifier] Paragraphe 3
The main side-effect of this rule is that it means a working copy has to do extra bookkeeping to track mixed revisions, and be tolerant of the mixture as well. It's made more complicated by the fact that directories themselves are versioned.
Le principal effet secondaire de cette règle est que cela veut dire que la copie de travail a de la comptabilité supplémentaire à effectuer pour suivre les mélanges de révision, et d'être tolérant vis-à-vis de ce mélange. Cela est rendu encore plus difficile du fait que les répertoires eux-mêmes peuvent être versionnés.
[modifier] Paragraphe 4
For example, suppose you have a working copy entirely at revision 10. You edit the file foo.html and then perform an svn commit, which creates revision 15 in the repository. After the commit succeeds, many new users would expect the working copy to be entirely at revision 15, but that's not the case! Any number of changes might have happened in the repository between revisions 10 and 15. The client knows nothing of those changes in the repository, since you haven't yet run svn update, and svn commit doesn't pull down new changes. If, on the other hand, svn commit were to automatically download the newest changes, then it would be possible to set the entire working copy to revision 15—but then we'd be breaking the fundamental rule of “push” and “pull” remaining separate actions. Therefore the only safe thing the Subversion client can do is mark the one file—foo.html—as being at revision 15. The rest of the working copy remains at revision 10. Only by running svn update can the latest changes be downloaded, and the whole working copy be marked as revision 15.
Par exemple, supposons que vous avez une copie de travail intégralement à la révision 10. Vous éditez le fichier foo.html et réaliser ensuite un svn commit, qui crée la révision 15 dans le dépôt. Après que la livraison a réussi, beaucoup de nouveaux utilisateurs s'attendraient à ce que toute la copie de travail soit à la révision 15, mais ce n'est pas le cas!
N'importe quelle quantité de modification peut avoir être effectuée dans le dépôt entre les révisions 10 et 15. Le client ne sait rien de ces changements dans le dépôt, puisqu'il n'a pas encore exécuté la commande svn update, et la commande svn commit ne récupére pas les nouvelles modifications. D'un autre côté, si la commande svn commit téléchargé automatiuquement les modifications les plus récentes, alors il serait possible d'avoir toute la copie de travail à la révision 15, mais dans ce cas, nous enfreindrions la règle fondamentale que "pousser" et "tirer" restent des actions séparés. Ainsi, la seul chose que le client Subversion peut faire en toute sécurité est de marquer le seul fichier foo.html comme étant à la révision 15. Le reste de la copie de travail reste à la révision 10. Seule l'exécution de la commande svn update permet de récupérer les dernières modificationset de marquer la copie de travail à la révision 15.[modifier] Paragraphe 5
Mixed revisions are normal
The fact is, every time you run svn commit, your working copy ends up with some mixture of revisions. The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in-between) your working copy will contain a whole mixture of revisions. Even if you're the only person using the repository, you will still see this phenomenon. To examine your mixture of working revisions, use the svn status --verbose command (see the section called “See an overview of your changes” for more information.)Des révisions mélangées sont normales
Le fait est que, à chaque fois que vous exécutez la commande svn commit, votre copie de travail se retrouve avec un mélange de révisions. Les éléments que vous venez juste de publier sont marqués comme ayant un numéro de révision supérieur à tous les autres. Après plusieurs livraison (sans mise à jour entre-temps), votre copie de travail va contenir tout un mélange de révisions. Même si vous êtes la seule personne à utiliser le dépôt, vous constaterez quand même ce phénoméne. Pour étudier ce mélange de révisions de travail, utilisez la commande svn status --verbose (voir la section "Avoir un aperçu de vos modifications" pour plus d'informations.[modifier] Paragraphe 6
Often, new users are completely unaware that their working copy contains mixed revisions. This can be confusing, because many client commands are sensitive to the working revision of the item they're examining. For example, the svn log command is used to display the history of changes to a file or directory (see the section called “Generating a list of historical changes”). When the user invokes this command on a working copy object, they expect to see the entire history of the object. But if the object's working revision is quite old (often because svn update hasn't been run in a long time), then the history of the older version of the object is shown.
Souvent, les nouveaux utilisateurs n'ont pas du tout conscience que leur copie de travail contient des révisions mélangées. Cela peut être déroutant, car beaucoup de commandes client sont sensibles à la révision de travail de l'élément qu'elles examinent. Par exemple, la commande svn log est utilisée pour afficher l'historique des modifications d'un fichier ou d'un répertoire (cf. section "Générer un historique des modifications"). Lorsque l'utilisateur appelle cette commande sur un objet de la copie de travail, il s'attend à avoir l'historique complet de celui-ci. Mais si la révision de travail de l'objet est assez ancienne (souvent parce que svn update n'a pas été lancé depuis un certain temps), alors c'est l'historique de l'ancienne version de l'objet qui est affiché.
[modifier] Paragraphe 7
Mixed revisions are useful
If your project is sufficiently complex, you'll discover that it's sometimes nice to forcibly backdate (or, update to a revision older than the one you already have) portions of your working copy to an earlier revision; you'll learn how to do that in Chapter 2, Basic Usage. Perhaps you'd like to test an earlier version of a sub-module contained in a subdirectory, or perhaps you'd like to figure out when a bug first came into existence in a specific file. This is the “time machine” aspect of a version control system—the feature which allows you to move any portion of your working copy forward and backward in history.Un mélange de révisions est utile
Si votre projet est suffisamment complexe, vous allez découvrir qu'il est parfois pratique de forcer un retour en arrière (c'est à dire faire une mise à jour vers une version plus anciennes que celle que vous avez déjà) sur certaines parties de votre copie de travail vers des révisions plus anciennes; vous apprendrez comme le faire dans le chapitre 2, Utilisation de Base. Peut-être que vous aimeriez tester une version précédente d'un sous-module contenu dans un répertoire, ou peut-être que vous aimeriez comprendre comme un bogue est pour la première apparu dans un ficher spécifique. C'est le côté "machine à voyager dans le temps" d'un système de gestion de version, la fonctionnalité qui vous permet de déplacer n'importe quelle partie de votre copie de travail en avant ou en arrière dans le temps.[modifier] Paragraphe 8
Mixed revisions have limitations
However you make use of mixed revisions in your working copy, there are limitations to this flexibility.Le mélange de révision possède des limitations
Quelque soit la façon dont vous utilisez le mélange de révision dans votre copie de travail, il existe des limitations à cette flexibilité.[modifier] Paragraphe 9
First, you cannot commit the deletion of a file or directory which isn't fully up-to-date. If a newer version of the item exists in the repository, your attempt to delete will be rejected, to prevent you from accidentally destroying changes you've not yet seen.
Premièrement, vous ne pouvez pas publier la suppression d'un fichier ou d'un répertoire qui n'est pas totalement mis à jour. Si une version plus récente de l'élément existe dans le dépôt, votre tentative de suppression sera rejetée, pour vous empêcher de détruire accidentellement des modifications que vous n'avez pas vu.
[modifier] Paragraphe 10
Second, you cannot commit a metadata change to a directory unless it's fully up-to-date. You'll learn about attaching “properties” to items in Chapter 3, Advanced Topics. A directory's working revision defines a specific set of entries and properties, and thus committing a property change to an out-of-date directory may destroy properties you've not yet seen.
Deuxièmement, vous ne pouvez pas livrer une modification de métadonnée dans un répertoire à moins que celui-ci ne soit parfaitement à jour. Vous apprendrez comment attacher des "propriétés" à des éléments dans le chapitre 3, Sujets Avancés. La révision de travail d'un répertoire définit un ensemble précis d'entrées et de propriétés, et livrer une modification de propriété effectuée sur un répertoire périmé peut donc amener à détruire des propriétés que vous n'aviez pas vu.
