You've already read about working copies; now we'll demonstrate how the Subversion client creates and uses them.
A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. You can even have multiple working copies of the same project.
Vous avez déjà découvert ce que sont les copies de travail ; nous allons maintenant vous montrer comment le client Subversion les crée et les utilise.
Une copie de travail Subversion est une arborescence classique de répertoires sur votre système local, contenant un ensemble de fichiers. vous pouvez éditer ces fichiers comme vous le voulez, et s'il s'agit de fichiers de code source, vous pouvez compiler votre programme à partir de ceux-ci de la façon habituelle. Votre copie de travail est votre espace de travail personnel : Subversion n'y incorporera jamais les changements des autres personnes, et ne rendra jamais disponible aux autres vos propres changements, tant que vous ne lui demandez pas explicitement de le faire. Vous pouvez même avoir plusieurs copies de travail pour un même projet.
After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to “publish” your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working directory (by reading from the repository).
Après avoir effectué quelque changements dans les fichiers de votre copie de travail, et vérifié qu'ils fonctionnent correctement, Subversion vous fournit des commandes pour publier vos changements aux autres personnes travaillant avec vous sur votre projet (en les écrivant dans le dépôt). Si d'autres personnes publient leurs propres changements, Subversion vous fournit des commandes pour fusionner ces changements dans votre répertoire de travail (en les lisant depuis le dépôt).
A working copy also contains some extra files, created and maintained by Subversion, to help it carry out these commands. In particular, each directory in your working copy contains a subdirectory named .svn, also known as the working copy administrative directory. The files in each administrative directory help Subversion recognize which files contain unpublished changes, and which files are out-of-date with respect to others' work.
Une copie de travail contient également quelques fichiers supplémentaires, créés et maintenus par Subversion, pour l'aider à effectuer ces commandes. En particulier, chaque répertoire dans votre copie de travail contient un sous-répertoire appelé .svn, aussi appelé répertoire administratif de votre copie de travail. Les fichiers de chacun de ces répertoires administratifs aident Subversion à reconnaître quels fichiers contient des modifications non-publiées, et quels fichiers sont périmés vis-à-vis du travail des autres.
A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.
Un dépôt Subversion typique contient souvent des fichiers (ou code source) de plusieurs projets ; habituellement, chaque projet est un sous-répertoire dans arborescence du système de fichiers du dépôt. Dans cette situation, la copie de travail d'un utilisateur correspond à un sous-arbre particulier du dépôt.
For example, suppose you have a repository that contains two software projects, paint and calc. Each project lives in its own top-level subdirectory, as shown in Figure 1.6, “The repository's filesystem”.
Par exemple, supposons que votre dépôt contienne deux projets logiciels, paint et calc. Chaque projet vit dans son propre sous-répertoire de plus haut niveau, comme montré dans la figure 1.6 "Le système de fichiers du dépôt".
To get a working copy, you must check out some subtree of the repository. (The term “check out” may sound like it has something to do with locking or reserving resources, but it doesn't; it simply creates a private copy of the project for you.) For example, if you check out /calc, you will get a working copy like this:
Pour obtenir une copie de travail, vous devez extraire un sous-arbre du répertoire. (Le terme "extraire" ("check out" en anglais) peut vous faire penser que cela a quelque chose à voir avec verrouiller ou réserver des ressources, mais ce n'est pas le cas ; cela crée simplement pour vous une copie privée du projet.) Par exemple, si vous extrayez /calc, vous obtiendrez une copie de travail qui ressemblera à ça:
$ svn checkout http://svn.example.com/repos/calc
A calc/Makefile
A calc/integer.c
A calc/button.c
Checked out revision 56.
$ ls -A calc
Makefile integer.c button.c .svn/
The list of letter A's in the left margin indicates that Subversion is adding a number of items to your working copy. You now have a personal copy of the repository's /calc directory, with one additional entry—.svn—which holds the extra information needed by Subversion, as mentioned earlier.
La liste de lettres A dans la marge de gauche indique que Subversion ajoute des éléments dans votre copie de travail. Vous avez désormais votre copie personnelle du répertoire /calc du dépôt, avec une entrée supplémentaire, .svn, qui contient des informations complémentaires nécessaires pour Subversion, comme évoqué précédemment.
Suppose you make changes to button.c. Since the .svn directory remembers the file's original modification date and contents, Subversion can tell that you've changed the file. However, Subversion does not make your changes public until you explicitly tell it to. The act of publishing your changes is more commonly known as committing (or checking in) changes to the repository.
--Danarmk 21 septembre 2007 à 21:52 (CEST):
Je viens de remplacer "livrer", traduction proposée de "commit", par "Envoyer", je trouve que ça passe mieux, vous en pensez quoi ?
--Penguin 21 septembre 2007 à 23:11 (CEST):
Je ne pense pas que ce soit une bonne idée car la version française de TortoiseSVN utilise le terme livrer (c'est pour cela que je l'ai utilisé).
Supposons que vous fassiez des modifications à button.c. Comme le répertoire .svn se souvient de la date de modification et du contenu du fichier original, Subversion peut déterminer que vous avec modifié le fichier. Néanmoins, Subversion ne rend pas vos modifications publiques tant que vous ne lui dites pas de le faire. L'action de publication de vos modifications est plus communément appelée livraison ("commit" en anglais) (ou archivage ("check in" en anglais)) des modifications dans le dépôt.
Now your changes to button.c have been committed to the repository, with a note describing your change (namely, that you fixed a typo). If another user checks out a working copy of /calc, they will see your changes in the latest version of the file.
Maintenant que vos modifications de button.c ont été livrées dans le dépôt, avec une note décrivant vos modifications (c'est à dire, que vous avez corrigé une coquille). Si un autre utilisateur extrait une copie de travail de /calc, il va voir vos modifications dans la dernière version du fichier.
Suppose you have a collaborator, Sally, who checked out a working copy of /calc at the same time you did. When you commit your change to button.c, Sally's working copy is left unchanged; Subversion only modifies working copies at the user's request.
Supposons que vous ayez une collaboratrice, Sally, qui a extrait une copie de travail de /calc en même temps que vous. Lorsque vous livrez votre modification à button.c, la copie de travail de Sally reste inchangée ; Subversion ne modifie les copies de travail qu'à la demande des utilisateurs.
To bring her project up to date, Sally can ask Subversion to update her working copy, by using the Subversion update command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.
Pour mettre son projet à jour, Sally peut demander à Subversion de mettre à jour ("update" en anglais) sa copie de travail, en utilisant la commande Subversion update. Cela va intégrer vos modifications dans sa copie de travail, tout comme celles qui ont été envoyées par les autres personnes depuis qu'elle l'avait extrait.
$ pwd
/home/sally/calc
$ ls -A
.svn/ Makefile integer.c button.c
$ svn update
U button.c
Updated to revision 57.
The output from the svn update command indicates that Subversion updated the contents of button.c. Note that Sally didn't need to specify which files to update; Subversion uses the information in the .svn directory, and further information in the repository, to decide which files need to be brought up to date.
La sortie de la commande svn update indique que subversion a mis à jour le contenu de button.c. Remarquez que Sally n'a pas besoin de spécifier quels fichiers doivent être mis à jour ; Subversion utilise les informations contenues dans le répertoire .svn, ainsi que d'autres informations en provenance du dépôt, pour décider quels fichiers doivent être mis à jour.
Subversion repositories can be accessed through many different methods—on local disk, or through various network protocols, depending on how your administrator has set things up for you. A repository location, however, is always a URL. Table 1.1, “Repository Access URLs” describes how different URL schemes map to the available access methods.
Table 1.1. Repository Access URLs
Schema Access Method
file:/// direct repository access (on local disk)
http:// access via WebDAV protocol to Subversion-aware Apache server
https:// same as http://, but with SSL encryption.
svn:// access via custom protocol to an svnserve server
svn+ssh:// same as svn://, but through an SSH tunnel.
For more information on how Subversion parses URLs, see the section called “Subversion Repository URLs”. For more information on the different types of network servers available for Subversion, see Chapter 6, Server Configuration.
URLs du dépôt
On peut accéder aux dépôts Subversion de beaucoup de méthodes différents, sur un disque local ou à travers différents protocoles réseau, en fonction de la façon dont votre administrateur a mis les choses en place pour vous. Un emplacement de dépôt, toutefois, est toujours une URL. Le tableau 1.1 "URLs d'accès au dépôt" décrit les différents procédés d'accès et les méthodes d'accès correspondantes.
Tableau 1.1 URLs d'accès au dépôt
Procédé Méthode d'accès
file:/// accès direct au dépôt (sur un disque local)
http:// accès via un protocole WebDAV pour serveur Apache configuré pour Subversion
https:// identique à http://, mais avec chiffrement SSL
svn:// accès via un protocole personnalisé à un serveur svnserve
svn+ssh:// identique à svn://, mais à travers un tunnel SSH
Pour plus d'informations sur la façon dont Subversion analyse les URLs, se reporter à la section "Les URLs du dépôt Subversion". Pour plus d'informations sur les différents types de serveurs réseaux disponibles pour Subversion, se reporter au Chapitre 6, Configuration serveur.