SVNBOOK Chap1 Subversion in Action Mixed Revision Working Copies
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Penguin | Traduction | Terminé | |
| SVF | 1ère Relecture | Fait | |
| HST | migration vers version 1.5 | Fait | |
| Relecture | |||
| Validation |
Sommaire |
Titre
Mixed Revision Working Copies
Copies de Travail Mixtes, à Révisions Mélangées
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 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é a tendance à embrouiller un certain nombre de nouveaux utilisateurs. Si l'exemple précédent contenant des révisions mixtes vous laisse perplexe, voici une amorce d'explication à la fois sur les raisons pour lesquelles cette fonctionnalité existe et sur la façon de l'utiliser.
Paragraphe 2
--Hotshot92 3 mars 2009 à 23:17 (CET):
Paragraphe mis à jour par la version 1.5
Updates and commits are separate
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull”, nor vice versa. 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 propagations sont deux choses distinctes
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 de nouvelles modifications encore en cours, alors svn update va élégamment fusionner les changements du dépôt avec les vôtres, plutôt que de vous forcer à les publier.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 as well as be tolerant of the mixture. It's made more complicated by the fact that directories themselves are versioned.
Le principal effet secondaire de cette règle est que la copie de travail a de la comptabilité supplémentaire à effectuer pour suivre les mélanges de révision et également être tolérant vis-à-vis de l'ensemble. Cela est rendu encore plus difficile par le fait que les répertoires eux-mêmes sont versionnés.
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, 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 ayez une copie de travail qui soit intégralement à la révision 10. Vous éditez le fichier truc.html et réalisez ensuite un svn commit, qui crée la révision 15 dans le dépôt. Après que la propagation ait 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 !
Un nombre quelconque de modifications ont pu avoir lieu dans le dépôt entre les révisions 10 et 15. Le client ne sait rien de ces changements qui ont été apportés au dépôt, puisque vous n'avez 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échargait automatiquement 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 selon laquelle "pousser" et "tirer" doivent demeurer des actions distinctes. Ainsi, la seule chose que le client Subversion peut faire en toute sécurité est de marquer le fichier, truc.html, et lui seulement, 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 permettra de récupérer les dernières modifications et de marquer la copie de travail comme étant à la révision 15.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 composée d'un mélange de révisions. Les éléments que vous venez juste de propager sont marqués comme ayant un numéro de révision plus élevé que tous les autres. Après plusieurs propagations (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 votre propre mélange de révisions de travail, utilisez la commande svn status --verbose (voir la section intitulée "Avoir un aperçu de vos modifications" pour plus d'informations).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, he expects 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 à obtenir 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é.
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 submodule 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 that 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 ancienne 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. Vous voudrez peut-être tester une version précédente d'un sous-module contenu dans un sous-répertoire, ou bien comprendre comme un bogue est apparu pour la première fois dans un fichier donné. C'est le côté "machine à voyager dans le temps" d'un système de gestion de versions, 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.Paragraphe 8
Mixed revisions have limitations
However you make use of mixed revisions in your working copy, there are limitations to this flexibility.Les mélanges de révision ont des limites
Quelle que soit la façon dont vous utilisez les mélanges de révision dans votre copie de travail, il existe des limites à cette flexibilité.Paragraphe 9
First, you cannot commit the deletion of a file or directory that 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 propager la suppression d'un fichier ou d'un répertoire qui n'est pas complètement à jour. Si une version plus récente de l'élément existe dans le dépôt, votre tentative de suppression sera rejetée, afin de vous empêcher de détruire accidentellement des modifications dont vous n'aviez pas encore connaissance.
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 propager la modification des métadonnées d'un répertoire que si celui-ci est complètement à jour. Vous apprendrez comment associer 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 propager la modification d'une propriété d'un répertoire périmé risquerait de détruire des propriétés dont vous n'aviez pas encore connaissance.
--Sub Versif 3 mars 2009 à 11:32 (CET):
Titre du chapitre 3 à corriger/valider une fois le titre traduit.
