SVNBOOK Chap1 Subversion in Action Revisions

De Framalang Wiki.

Cette page fait partie du projet Version control with subversion.


Pseudo Code Rôle Statut
Penugin Traduction Terminé
SVF 1ère Relecture Fait
HST Mise à jour en version 1.5 Fait
Relecture
Validation



Sommaire

Titre

Revisions
Révisions

Paragraphe 1

An svn commit operation publishes changes to any number of files and directories as a single atomic transaction. In your working copy, you can change files' contents; create, delete, rename and copy files and directories; then commit a complete set of changes as an atomic transaction.
Une opération svn commit publie les modifications d'un nombre quelconque de fichiers et de répertoires en une seule opération atomique. Dans votre copie de travail, vous pouvez modifier le contenu des fichiers : créer, supprimer, renommer et copier fichiers et répertoires ; puis propager un ensemble de modifications en une seule transaction atomique.

Paragraphe 2

By “atomic transaction”, we mean simply this: either all of the changes happen in the repository, or none of them happen. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
Par "transaction atomique", on entend simplement ceci : soit toutes les modifications sont propagées dans le dépôt, soit aucune ne l'est. Subversion essaie de conserver cette atomicité vis-à-vis des plantages du programme, du système ou du réseau, et vis-à-vis des actions des autres utilisateurs.

Paragraphe 3

Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number of the previous revision. The initial revision of a freshly created repository is numbered zero, and consists of nothing but an empty root directory.
Chaque fois que le dépôt accepte une propagation, ceci crée un nouvel état de l'arborescence du système de fichiers, appelé révision. Un numéro unique est associé à chaque révision, correspondant au numéro de la révision précédente augmenté de 1. La révision initiale d'un dépôt fraîchement créé porte le numéro 0 et ne consiste en rien d'autre qu'un répertoire racine vide.

Paragraphe 4

Figure 1.7, “The repository” illustrates a nice way to visualize the repository. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a “snapshot” of the way the repository looked after a commit.
La figure 1.7, "Le dépôt", offre une vue intéressante du dépôt. Imaginez un tableau de numéros de révisions, commençant à 0 et s'étirant de la gauche vers la droite. Chaque numéro de révision correspond à une arborescence de système de fichiers située en-dessous de lui, et chaque arborescence est un "instantané" ("snapshot" en anglais) de ce à quoi ressemble le dépôt après une propagation.

Paragraphe 5

Global Revision Numbers

Unlike most version control systems, Subversion's revision numbers apply to entire trees, not individual files. Each revision number selects an entire tree, a particular state of the repository after some committed change. Another way to think about it is that revision N represents the state of the repository filesystem after the Nth commit. When Subversion users talk about “revision 5 of foo.c”, they really mean “foo.c as it appears in revision 5.” Notice that in general, revisions N and M of a file do not necessarily differ! Many other version control systems use per-file revision numbers, so this concept may seem unusual at first. (Former CVS users might want to see Appendix B, Subversion for CVS Users for more details.)

Numéros de révision globaux

Contrairement à la plupart des systèmes de gestion de versions, les numéros de révision de Subversion s'appliquent à l'arborescence toute entière, pas à chaque fichier individuellement. A chaque numéro de révision correspond une arborescence toute entière, un état particulier du dépôt après une propagation de modifications. Une autre façon de voir cela est de considérer que la révision N représente l'état du système de fichiers du dépôt après la Nième propagation. Quand des utilisateurs de Subversion parlent de la "révision 5 de truc.c", ils veulent parler en fait de "truc.c tel qu'il apparaît dans la révision 5". Remarquez bien qu'en règle générale, les révisions N et M d'un fichier ne sont pas forcément différentes ! Beaucoup d'autres systèmes de gestion de versions utilisent des numéros de révision gérés par fichier, ce concept peut donc sembler inhabituel à première vue. (Les anciens utilisateurs de CVS peuvent se référer à l'appendice B, "Subversion pour les utilisateurs de CVS" pour plus de détails).

Paragraphe 6

It's important to note that working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. For example, suppose you check out a working copy from a repository whose most recent revision is 4:
Il est important de noter que les copies de travail ne correspondent pas toujours à une unique révision dans le dépôt ; elles peuvent contenir des fichiers provenant de plusieurs révisions différentes. Par exemple, supposons que vous extrayiez une copie de travail d'un dépôt dont la révision la plus récente est la 4 :
calc/Makefile:4
    integer.c:4
    button.c:4
calc/Makefile:4
    entier.c:4
    bouton.c:4

Paragraphe 7

At the moment, this working directory corresponds exactly to revision 4 in the repository. However, suppose you make a change to button.c, and commit that change. Assuming no other commits have taken place, your commit will create revision 5 of the repository, and your working copy will now look like this:
A cet instant, le répertoire de travail correspond exactement à la révision 4 du dépôt. Néanmoins, supposons que vous effectuiez une modification à bouton.c, et que vous propagiez cette modification. En supposant qu'aucune autre propagation n'a eu lieu, votre propagation va créer la révision 5 du dépôt, et votre copie de travail va maintenant ressembler à ceci :
calc/Makefile:4
    entier.c:4
    bouton.c:5

Paragraphe 8

Suppose that, at this point, Sally commits a change to integer.c, creating revision 6. If you use svn update to bring your working copy up to date, it will look like this:
Supposons maintenant qu'à ce moment, Sally propage une modification à entier.c, créant la révision 6. Si vous utilisez svn update pour mettre à jour votre copie de travail, elle va alors ressembler à ceci :
calc/Makefile:6
    integer.c:6
    button.c:6
calc/Makefile:6
    entier.c:6
    bouton.c:6

Paragraphe 9

Sally's change to integer.c will appear in your working copy, and your change will still be present in button.c. In this example, the text of Makefile is identical in revisions 4, 5, and 6, but Subversion will mark your working copy of Makefile with revision 6 to indicate that it is still current. So, after you do a clean update at the top of your working copy, it will generally correspond to exactly one revision in the repository.
Les modifications apportées par Sally à entier.c vont apparaître dans votre copie de travail, et vos modifications seront toujours présentes dans bouton.c. Dans cet exemple, le texte de Makefile est identique dans les révisions 4, 5 et 6, mais Subversion va marquer votre copie de travail comme étant à la révision 6 pour indiquer qu'elle est à jour. Ainsi, quand vous effectuez une mise à jour au niveau de la racine de votre copie de travail, celle-ci correspondra en général à une révision donnée du dépôt.
Outils personnels