La commande svn import est un moyen rapide de copier une arborescence non-suivie en versions dans le dépôt, créant des dossiers intermédiaires si nécessaire. svn import ne nécessite pas de copie de travail et vos fichiers sont immédiatement propagés dans le dépôt. Ce moyen est utilisé essentiellement quand vous avez une arborescence existante dont vous voulez suivre les changements dans votre dépôt Subversion. Par exemple :

$ svn import chemin/vers/mon/arborescence \
             http://svn.exemple.com/svn/depot/un/projet \
             -m "Import initial"
Ajout         mon-arborescence/truc.c
Ajout         mon-arborescence/machin.c
Ajout         mon-arborescence/sous-repertoire
Ajout         mon-arborescence/sous-repertoire/bidule.h

Révision 1 propagée.
$

L'exemple précédent copie le contenu d'un dossier local mon-arborescence dans le dossier un/projet du dépôt. Notez que vous n'avez pas eu besoin de créer d'abord ce nouveau dossier, svn import le faisant pour vous. Immédiatement après la propagation, vous pouvez voir vos données dans le dépôt :

$ svn list http://svn.exemple.com/svn/depot/un/projet
machin.c
sous-repertoire/
truc.c
$

Notez qu'après la fin de l'import, l'arborescence d'origine n'est pas transformée en copie de travail. Pour commencer à travailler, vous devez extraire grâce à svn checkout une copie de travail toute fraîche de l'arborescence.

On ne peut pas être plus flexible que Subversion pour l'organisation de vos données. Comme il ne fait que suivre en versions les fichiers et les dossiers et comme il n'attache aucune sémantique à ces objets, vous avez tout loisir de disposer les données dans votre dépôt comme bon vous semble. Malheureusement, la contrepartie de cette flexibilité est qu'il est facile de se retrouver perdu quand on essaye de parcourir différents dépôts Subversion, les schémas de stockage des données pouvant être très différents voire imprévisibles.

Pour pallier cette confusion possible, nous vous recommandons de suivre la convention suivante (établie il y a bien longtemps, avec l'éclosion du projet Subversion lui-même) qui consiste à nommer judicieusement quelques dossiers du dépôt Subversion en fonction des données qu'ils renferment. La plupart des projets possèdent « une ligne de développement principale » identifiable, autrement appelée tronc (trunk en anglais), des branches, qui sont des copies avec des variantes de la ligne de développement principale et des étiquettes (tags en anglais) qui sont des instantanés de la ligne de développement que l'on a nommés. En conséquence, nous recommandons premièrement que chaque projet dispose d'une racine de projet bien identifiée au sein du dépôt, un dossier sous lequel toutes les données du projet — et uniquement les données du projet — seront hébergées. Deuxièmement, nous recommandons que chaque racine de projet contienne un sous-dossier trunk pour la ligne de développement principale, un sous-dossier branches dans lequel les branches spécifiques (ou groupes de branches) seront créées et un sous-dossier tags dans lequel seront placés les instantanés (ou les groupes d'instantanés). Bien sûr, si un dépôt n'héberge qu'un seul projet, la racine du dépôt peut servir de racine du projet.

Voici quelques exemples :

$ svn list file:///var/svn/depot-projet-unique
trunk/
branches/
tags/
$ svn list file:///var/svn/depot-multiples-projets
projet-A/
projet-B/
$ svn list file:///var/svn/depot-multiples-projets/projet-A
trunk/
branches/
tags/
$

Vous en apprendrez plus sur les étiquettes et les branches dans le Chapitre 4, Gestion des branches. Pour plus de détails et pour voir comment gérer plusieurs projets, reportez-vous à la section intitulée « Agencement du dépôt », et à la section intitulée « Stratégies d'organisation d'un dépôt » pour en savoir plus sur les dossiers racines d'un projet.

Subversion s'efforce de ne pas limiter le type de données que vous placez en suivi de versions. Le contenu des fichiers et les valeurs des propriétés sont stockés et transmis en tant que données binaires. la section intitulée « Type de contenu des fichiers » vous explique comment indiquer à Subversion que des opérations « textuelles » n'ont pas de sens pour un fichier particulier. Il existe toutefois quelques cas pour lesquels Subversion définit des limitations sur les informations qu'il stocke.

Subversion gère en interne certaines parties des données au format Unicode UTF-8, par exemple les noms de propriétés, les noms de chemins et les messages de trace. Cela ne veut toutefois pas dire que toutes vos interactions avec Subversion doivent faire intervenir l'UTF-8. En règle générale, les clients Subversion vont gérer de façon transparente les conversions entre l'UTF-8 et le système de codage utilisé par votre ordinateur, si cela a un sens de faire une telle conversion (ce qui est le cas pour les codages les plus courants utilisés de nos jours).

Dans les échanges WebDAV ainsi que dans des anciennes versions de certains fichiers de gestion interne de Subversion, les chemins sont utilisés en tant que valeurs d'attribut XML et les noms de propriétés en tant que noms de tags XML. Cela veut dire que les chemins ne peuvent contenir que des caractères XML (1.0) valides et que les noms de propriétés sont encore plus limités, ne pouvant contenir que des caractères ASCII. Subversion interdit également les caractères TAB (tabulation), CR et LF (caractères de fin de ligne) dans les noms de chemins pour empêcher les chemins d'être coupés en deux lors des comparaisons ou dans les sorties de commandes comme svn log ou svn status.

Bien que cela fasse beaucoup de choses à se rappeler, ces limitations sont rarement un problème en pratique. Tant que vos paramètres régionaux sont compatibles avec UTF-8 et que vous n'utilisez pas de caractères de contrôle dans les chemins, vous ne devriez pas avoir de problème pour communiquer avec Subversion. Le client texte interactif apporte un peu d'aide supplémentaire : afin de créer des versions « valides » pour un usage interne, il banalise automatiquement, si nécessaire, les caractères illégaux contenus dans les chemins d'URL que vous tapez.

Avertissement

Évidemment, au moment de choisir des noms de chemins valides, Subversion n'est pas l'unique facteur limitant. Les équipes qui travaillent avec plusieurs systèmes d'exploitation doivent aussi prendre en compte les limitations imposées par ces systèmes d'exploitation. Par exemple, Windows n'autorise pas l'utilisation de la virgule dans les noms de fichiers alors qu'un utilisateur de Linux peut très bien placer un tel fichier en suivi de versions, générant des données qui ne pourront plus être extraites sous Windows. De même, ajouter plusieurs fichiers dont les noms ne diffèrent que par la casse entraîne des problèmes pour les utilisateurs de systèmes de fichiers non sensibles à la casse. En conséquence, nous vous recommandons de bien prendre aussi en compte les limitations posées par les différents systèmes d'exploitation et systèmes de fichiers.