Bien que Subversion vous permette de déplacer des fichiers et des répertoires suivis en versions sans perte d'information et qu'il fournisse même des outils pour déplacer des ensembles complets de données suivies en version d'un dépôt à un autre, ces opérations peuvent perturber le travail des autres collaborateurs qui accèdent souvent au dépôt et qui s'attendent à trouver chaque chose à sa place. Ainsi, avant de créer un nouveau dépôt, essayez de vous projeter un peu dans le futur ; préparez à l'avance le passage de vos données sous gestion de versions. Cette réflexion sur la manière d'organiser vos données dans le dépôt vous évitera de futurs et nombreux maux de tête.

Supposons qu'en tant qu'administrateur d'un dépôt, vous êtes responsable de l'administration du système de gestion de versions pour plusieurs projets. La première décision à prendre est de choisir entre un seul dépôt pour tous les projets et un dépôt par projet, ou bien un compromis entre ces deux solutions.

Un seul dépôt pour tous les projets offre des avantages, ne serait-ce que pour la maintenance unifiée. Un seul dépôt signifie qu'il n'y a qu'un seul jeu de procédures automatiques, une seule sauvegarde à gérer, un seul jeu d'opérations de déchargement et de chargement à effectuer si la nouvelle version de Subversion est incompatible avec l'ancienne version, etc. Vous pouvez également déplacer facilement des données entre les projets, sans perdre l'historique de ces informations.

Les inconvénients à utiliser un seul dépôt sont que les différents projets auront certainement des besoins différents en termes de gestion des événements, comme la notification par e-mail des propagations à des listes d'adresses différentes ou des définitions différentes de ce qui constitue une propagation légitime. Bien sûr, ce ne sont pas des problèmes insurmontables — cela implique juste que vos procédures automatiques doivent tenir compte de l'organisation du dépôt dans lequel elles sont invoquées plutôt que de considérer que l'ensemble du dépôt est associé à un seul groupe d'utilisateurs. Rappelez-vous également que Subversion utilise des numéros de révisions globaux au dépôt. Bien que ces numéros ne possèdent pas de pouvoirs magiques particuliers, certaines personnes n'aiment pas voir le numéro de révision augmenter alors qu'elles n'ont pas touché à leur propre projet^[52].

On peut aussi adopter une approche intermédiaire. Par exemple, les projets peuvent être regroupés par thème. Vous pouvez avoir quelques dépôts, avec une poignée de projets dans chaque dépôt. Ainsi, les projets susceptibles de partager des données le font aisément et les développeurs sont tenus au courant des avancées des projets en relation avec les leurs par le biais des nouvelles révisions du dépôt.

Une fois l'organisation des dépôts définie, il faut se préoccuper de la hiérarchie des répertoires à l'intérieur des dépôts eux-mêmes. Comme Subversion utilise de simples copies de répertoires pour créer les branches et les étiquettes (voir le Chapitre 4, Gestion des branches), la communauté Subversion recommande de choisir un endroit dans le dépôt pour la racine de chaque projet (le répertoire dont la sous-arborescence contient toutes les données relatives à un projet) et d'y placer trois sous-répertoires : trunk (« tronc » en français), le dossier qui héberge les principaux développements du projet ; branches, le dossier dans lequel seront créées les différentes variations de la ligne de développement principale ; et tags (« étiquettes » en français), qui contient un ensemble d'instantanés de l'arborescence (les instantanés sont créés, voire détruits, mais jamais modifiés)^[53].

Par exemple, votre dépôt peut ressembler à ceci :

Veuillez noter que l'emplacement du projet dans le dépôt n'est pas important. Si vous n'avez qu'un seul projet par dépôt, il est logique de placer la racine du projet à la racine du dépôt correspondant. Si vous avez plusieurs projets, vous voulez peut-être les classer par groupes dans des sous-répertoires communs du dépôt, en fonction des objectifs ou du code à partager par exemple, ou tout simplement en les groupant par ordre alphabétique. Voici un exemple :

Organisez votre dépôt comme vous le sentez. Subversion n'a aucune exigence en la matière — pour lui, un répertoire est un répertoire. L'objectif est d'avoir une organisation qui réponde aux besoins des collaborateurs des différents projets.

Cependant, par souci de transparence, nous indiquons une autre organisation également très répandue. Dans cette organisation, les répertoires trunk, tags et branches sont situés à la racine du dépôt et les projets sont placés dans des sous-répertoires juste en dessous, comme ceci :

Il n'y a rien d'incorrect dans une telle organisation, mais elle peut ne pas être très intuitive pour vos utilisateurs. En particulier dans des situations complexes avec plusieurs projets et un grand nombre d'utilisateurs, dont la plupart ne connaissent qu'un ou deux projets du dépôt. Mais cette approche « plusieurs projets par branche » a tendance à favoriser l'ouverture de chaque projet sur les autres et pousse à envisager l'ensemble des projets comme une seule entité. Cela reste un problème social. Nous aimons l'organisation suggérée au début pour des raisons purement pratiques : il est plus facile de faire des requêtes (ou des modifications, des migrations) sur l'historique complet d'un projet quand une sous-arborescence du dépôt contient l'ensemble des données (passé, présent, étiquettes et branches) de ce projet et elles seules.

Avant de créer votre dépôt Subversion, vous devez vous demander où il va résider. Cette question est fortement liée à une myriade d'autres questions telles que  : qui sont les utilisateurs (sont-ils à l'intérieur de votre réseau interne, derrière le pare-feu de votre entreprise, ou bien s'agit-il de n'importe qui, n'importe où sur Internet ?), comment les utilisateurs accèdent au dépôt (via un serveur Subversion ou directement), quels autres services vous fournissez autour de Subversion (une interface pour navigateur Web, des notifications par email des propagations, etc.), quelle est votre politique de sauvegarde et ainsi de suite.

Le choix et la configuration du serveur sont abordés au Chapitre 6, Configuration du serveur, mais nous voulons signaler dès maintenant que certains choix pour l'une ou l'autre de ces questions ont des implications sur l'endroit où implémenter votre serveur. Par exemple, certains scénarios de déploiement nécessitent, pour plusieurs ordinateurs, l'accès au dépôt via un système de fichiers distant ou l'utilisation de plusieurs dépôts dont les contenus sont répartis géographiquement afin d'offrir des accès performants à tous les utilisateurs quels que soient leurs emplacements. Étudier chaque cas possible de déploiement de Subversion est à la fois impossible et hors du champ de ce livre. Nous vous encourageons simplement à considérer les différentes options présentées dans ces pages et ailleurs dans d'autres références, puis de planifier vos déploiements en conséquence.

Le contrôle d'accès dans Subversion est presqu'entièrement géré par le processus serveur. Nous abordons les serveurs fournis par Subversion dans Chapitre 6, Configuration du serveur et nous expliquons le contrôle d'accès basé sur les chemins spécifiquement dans la section intitulée « Contrôle d'accès basé sur les chemins ». En complément du contrôle d'accès des utilisateurs, vous devez vous assurer de l'accès à votre dépôt par les programmes hébergés sur votre machine et qui ont besoin cet accès. Là encore, reportez-vous à Chapitre 6, Configuration du serveur pour trouver toutes les informtions utiles pour prendre vos décisions.