Subversion assure le suivi de l'arborescence entière, pas seulement des fichiers. C'est une des raisons majeures pour lesquelles Subversion a été créé, dans le but de se substituer à CVS.
Voilà ce que cela implique, du point de vue d'un ancien utilisateur de CVS :
Les commandes svn add et svn
delete fonctionnent désormais aussi sur les
répertoires, de la même manière que sur les fichiers. Idem
pour svn copy et
svn move. Cependant, ces commandes n'ont
pas d'effet immédiat sur le dépôt ; en effet, elles ne
font que planifier l'ajout ou la
suppression des éléments concernés. Aucun changement n'a lieu
dans le dépôt tant que vous n'effectuez pas de propagation
(commande svn commit).
Les répertoires ne sont plus de simples conteneurs ;
ils possèdent un numéro de révision tout comme les fichiers
(ou pour être plus précis, il faut parler du « répertoire
machin/ tel qu'il était à la révision
5 »).
Approfondissons ce dernier point. La gestion de versions d'un répertoire est un problème difficile ; comme nous voulons autoriser des copies de travail à cheval sur plusieurs révisions, des limitations apparaissent quand on essaie de pousser le modèle trop loin.
D'un point de vue théorique, nous définissons « la
révision 5 du répertoire machin » comme
un ensemble d'entrées et de propriétés du répertoire. Maintenant,
supposons que nous ajoutons et supprimons des fichiers de
machin, puis que nous propageons ces
modifications. Dire que nous avons toujours la révision 5 de
machin est un mensonge. Cependant, si nous
changeons le numéro de révision de
machin après la propagation, c'est aussi un
mensonge ; il peut y avoir d'autres changements sur
machin que nous n'avons pas encore reçus
parce que nous n'avons pas encore effectué de mise à jour
(commande svn update).
Subversion traite ce problème en conservant discrètement, dans
la zone .svn, le détail des ajouts et des
suppressions propagés. Par la suite, quand vous lancez
svn update, ces informations sont prises en
compte et combinées avec celles du dépôt et le nouveau numéro de
révision du répertoire est alors positionné correctement. Ainsi,
c'est seulement après une mise à jour que vous pouvez
affirmer, sans risque de vous tromper, que vous disposez d'une
révision « parfaite » d'un répertoire.
La plupart du temps, votre copie de travail contient des
répertoires « imparfaitement » synchronisés.
De la même manière, un problème survient si vous essayez de propager des modifications de propriétés sur un répertoire. Normalement, la propagation devrait ajuster le numéro de révision du répertoire de la copie de travail locale. Mais là encore, ce serait un mensonge puisqu'il peut y avoir des ajouts et des suppressions que le répertoire n'a pas encore reçu en raison de la mise à jour qui n'a pas encore eu lieu. En conséquence, il n'est pas permis de propager des changements sur les propriétés d'un répertoire sans que ce répertoire ne soit préalablement mis à jour.
Pour plus d'informations sur les limitations de la gestion de versions des répertoires, reportez-vous à la section intitulée « Copies de travail mixtes, à révisions mélangées ».