Importer des données dans un référentiel
Précédent Chapitre 5. Guide d'utilisation quotidienne Suivant

Importer des données dans un référentiel

Importer

If you are importing into an existing repository which already contains some projects, then the repository structure will already have been decided. If are importing data into a new repository then it is worth taking the time to think about how it will be organised. Read la section intitulée « Disposition du référentiel » for further advice.

This section describes the Subversion import command, which was designed for importing a directory hierarchy into the repository in one shot. Although it does the job, it has several shortcomings:

  • There is no way to select files and folders to include, aside from using the global ignore settings.

  • The folder imported does not become a working copy. You have to do a checkout to copy the files back from the server.

  • It is easy to import to the wrong folder level in the repository.

For these reasons we recommend that you do not use the import command at all but rather follow the two-step method described in la section intitulée « Import in Place ». But since you are here, this is how the basic import works ...

Avant que vous n'importiez votre projet dans un référentiel, vous devriez :

  1. Supprimez tous les fichiers qui ne sont pas nécessaires pour générer le projet (fichiers temporaire, fichiers produits par un compilateur par exemple *.obj, binaires compilés...)

  2. Organisez les fichiers en dossiers et sous-dossiers. Bien qu'il soit possible de renommer/déplacer les fichiers plus tard, il est fortement recommandé d'obtenir la structure de votre projet juste avant l'importation !

Choisissez maintenant le dossier de niveau supérieur de votre structure de répertoire de projet dans l'explorateur Windows et faite un clic droit pour ouvrir le menu contextuel. Choisissez la commande TortoiseSVN → Importer... qui fait s'afficher une boîte de dialogue :

Figure 5.6. Le boîte de dialogue Importer

Le boîte de dialogue Importer


In this dialog you have to enter the URL of the repository location where you want to import your project. It is very important to realise that the local folder you are importing does not itself appear in the repository, only its content. For example if you have a structure: 

C:\Projects\Widget\source
C:\Projects\Widget\doc
C:\Projects\Widget\images

and you import C:\Projects\Widget into http://mydomain.com/svn/trunk then you may be surprised to find that your subdirectories go straight into trunk rather than being in a Widget subdirectory. You need to specify the subdirectory as part of the URL, http://mydomain.com/svn/trunk/Widget-X. Note that the import command will automatically create subdirectories within the repository if they do not exist.

Le message d'importation est utilisé comme un commentaire.

Par défaut, les fichiers et les dossiers qui correspondent au filtre d'exclusion ne sont pas importés. Pour ignorer ce comportement, vous pouvez utiliser la case à cocher Inclure les fichiers ignorés. Référez-vous à la section intitulée « Configuration générale » pour plus d'informations sur la configuration d'un filtre d'exclusion.

As soon as you press OK TortoiseSVN imports the complete directory tree including all files into the repository. The project is now stored in the repository under version control. Please note that the folder you imported is NOT under version control! To get a version-controlled working copy you need to do a Checkout of the version you just imported. Or read on to find out how to import a folder in place.

Import in Place

Assuming you already have a repository, and you want to add a new folder structure to it, just follow these steps:

  1. Utiliser le navigateur de référentiel pour créer un nouveau projet directement dans le référentiel.

  2. Checkout the new folder over the top of the folder you want to import. You will get a warning that the local folder is not empty. Now you have a versioned top level folder with unversioned content.

  3. Use TortoiseSVN → Add... on this versioned folder to add some or all of the content. You can add and remove files, set svn:ignore properties on folders and make any other changes you need to.

  4. Commit the top level folder, and you have a new versioned tree, and a local working copy, created from your existing folder.

Fichiers spéciaux

Parfois vous avez besoin d'avoir un fichier sous contrôle de version qui contient des données spécifiques à l'utilisateur. Cela signifie que vous avez un fichier que chaque développeur/utilisateur doit modifier pour convenir à son paramétrage local. Mais versionner un tel fichier est difficile parce que chaque utilisateur livrerait ses changements chaque fois au référentiel.

In such cases we suggest to use template files. You create a file which contains all the data your developers will need, add that file to version control and let the developers check this file out. Then, each developer has to make a copy of that file and rename that copy. After that, modifying the copy is not a problem anymore.

Comme exemple, vous pouvez regarder le script de construction de TortoiseSVN. Il appelle un fichier nommé TortoiseVars.bat qui n'existe pas dans le référentiel. Uniquement le fichier TortoiseVars.tmpl. TortoiseVars.tmpl est le fichier de modèle dont chaque développeur doit créer une copie et renommer ce fichier en TortoiseVars.bat. À l'intérieur de ce fichier, nous avons ajouté des commentaires pour que les utilisateurs voient quelles lignes ils doivent éditer et changer selon leur paramétrage local pour qu'il marche.

Afin de ne pas déranger les utilisateurs, nous avons aussi ajouté le fichier TortoiseVars.bat à la liste des ignorés de son dossier parent, c'est-à-dire nous avons mis la propriété Subversion svn:ignore pour inclure ce nom de fichier. De cette façon il n'apparaîtra pas comme non versionné à chaque livraison.

Projets référencés

Il est parfois utile de construire une copie de travail faite d'un certain nombre d'extractions différentes. Par exemple, vous pouvez vouloir que des sous-répertoires différents viennent d'emplacements différents dans un référentiel, ou peut-être de référentiels différents. Si vous voulez que chaque utilisateur ait la même disposition, vous pouvez définir les propriétés svn:externals.

Let's say you check out a working copy of /project1 to D:\dev\project1. Select the folder D:\dev\project1, right click and choose Windows Menu → Properties from the context menu. The Properties Dialog comes up. Then go to the Subversion tab. There, you can set properties. Click Add.... Select the svn:externals property from the combobox and write in the edit box the repository URL in the format name url or if you want to specify a particular revision, name -rREV url You can add multiple external projects, 1 per line. Note that URLs must be properly escaped or they will not work. For example you must replace each space with %20. Note that it is not possible to use folder names with spaces in them. Suppose that you have set these properties on D:\dev\project1: 

sounds   http://sounds.red-bean.com/repos
quick_graphs  http://graphics.red-bean.com/repos/fast%20graphics
skins/toolkit -r21 http://svn.red-bean.com/repos/skin-maker

Now click Set and commit your changes. When you (or any other user) update your working copy, Subversion will create a sub-folder D:\dev\project1\sounds and checkout the sounds project, another sub-folder D:\dev\project1\quick graphs containing the graphics project, and finally a nested sub-folder D:\dev\project1\skins\toolkit containing revision 21 of the skin-maker project.

Astuce

You should strongly consider using explicit revision numbers in all of your externals definitions, as described above. Doing so means that you get to decide when to pull down a different snapshot of external information, and exactly which snapshot to pull. Besides the common sense aspect of not being surprised by changes to third-party repositories that you might not have any control over, using explicit revision numbers also means that as you backdate your working copy to a previous revision, your externals definitions will also revert to the way they looked in that previous revision, which in turn means that the external working copies will be updated to match they way they looked back when your repository was at that previous revision. For software projects, this could be the difference between a successful and a failed build of an older snapshot of your complex code base.

Si le projet externe est dans le même référentiel, les changements que vous faites là seront inclus dans la liste de livraisons quand vous livrerez votre projet principal.

Si le projet externe est dans un référentiel différent, les changements que vous faites au projet externe seront signalés quand vous livrerez le projet principal, mais vous devez livrer ces changements externes séparément.

If you use absolute URLs in svn:externals definitions and you have to relocate your working copy (i.e., if the URL of your repository changes), then your externals won't change and might not work anymore.

To avoid such problems, Subversion clients version 1.5 and higher support relative external URLs. Four different methods of specifying a relative URL are supported. In the following examples, assume we have two repositories: one at http://example.com/svn/repos-1 and another at http://example.com/svn/repos-2. We have a checkout of http://example.com/svn/repos-1/project/trunk into C:\Working and the svn:externals property is set on trunk.

Relative to parent directory

These URLs always begin with the string ../ for example: 

../../widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo into C:\Working\common\foo-widget.

Note that the URL is relative to the URL of the directory with the svn:externals property, not to the directory where the external is written to disk.

Relative to repository root

These URLs always begin with the string ^/ for example: 

^/widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo into C:\Working\common\foo-widget.

You can easily refer to other repositories with the same SVNParentPath (a common directory holding several repositories). For example: 

^/../repos-2/hammers/claw  common/claw-hammer

This will extract http://example.com/svn/repos-2/hammers/claw into C:\Working\common\claw-hammer.

Relative to scheme

URLs beginning with the string // copy only the scheme part of the URL. This is useful when the same hostname must the accessed with different schemes depending upon network location; e.g. clients in the intranet use http:// while external clients use svn+ssh://. For example: 

//example.com/svn/repos-1/widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo or svn+ssh://example.com/svn/repos-1/widgets/foo depending on which method was used to checkout C:\Working.

Relative to the server's hostname

URLs beginning with the string / copy the scheme and the hostname part of the URL, for example: 

/svn/repos-1/widgets/foo  common/foo-widget

This will extract http://example.com/svn/repos-1/widgets/foo into C:\Working\common\foo-widget. But if you checkout your working copy from another server at svn+ssh://another.mirror.net/svn/repos-1/project1/trunk then the external reference will extract svn+ssh://another.mirror.net/svn/repos-1/widgets/foo.

Si vous avez besoin de plus d'informations sur la façon dont TortoiseSVN manipule les propriétés, lisez la section intitulée « Configuration des projets ».

Pour découvrir des méthodes différentes d'accéder aux sous-projets communs, lisez la section intitulée « Inclure un sous-projet commun ».

Précédent Niveau supérieur Suivant
Chapitre 5. Guide d'utilisation quotidienne Sommaire Extraire une copie de travail