Comment Subversion stocke-t-il exactement les fichiers dans le référentiel?
J'ai lu le livre Subversion et il est clair pour moi que Subversion ne stocke pas de fichiers individuels mais uniquement des deltas afin de minimiser l'espace disque. Subversion fait également la même chose avec les fichiers binaires (c'était une énorme faiblesse de CVS).
Cependant, je ne comprends pas le mécanisme exact. Lorsque je valide un fichier, que se passe-t-il?
- Subversion ne stocke que le diff (et a déjà l'ancienne version)
- Subversion supprime la version précédente, stocke le nouveau fichier intact et crée un différentiel inverse afin de "recréer" l'ancienne version si nécessaire.
- Quelque chose d'autre auquel je n'ai pas pensé.
Le premier cas peut sembler le plus logique. Cela soulève cependant une autre question. Si j'ai dans un référentiel Subversion un fichier avec 1000 commits et qu'un nouveau développeur extrait une copie propre, alors Subversion devrait récupérer la version originale (importation initiale) et appliquer 1000 différences sur ce avant de retourner le résultat. Est-ce correct? Existe-t-il une sorte de mise en cache des fichiers où la dernière version est également conservée?
Fondamentalement, où puis-je trouver des informations sur les éléments internes du référentiel svn?
pdate: Apparemment, le backend de Subversion joue un grand rôle dans ce domaine. Au moment de l'écriture ou FSFS utilise l'option 1 tandis que BDB utilise l'option 2. Merci msemack!
Étant donné que le format de référentiel de Subversion est entièrement interne, ils sont libres de changer la représentation d'une révision à la suivante. Je pense que la révision actuelle stocke généralement des deltas inverses (votre option 2), mais stocke également des instantanés complets de façon à ce qu'il n'ait pas à résoudre 1000 différences avant de renvoyer un résultat.
Les notes de publication de Subversion 1.6 ont une section sur améliorations du stockage du système de fichiers qui contient quelques notes à ce sujet et des liens vers d'autres sources. Autant dire que les détails du stockage des données Subversion sont complexes et susceptibles de changer.
Il existe également un document de conception dans l'arborescence source de Subversion qui décrit l'utilisation de ignorer les deltas dans Subversion . Généralement, le répertoire / notes / contient plusieurs documents utiles concernant les internes de Subversion.
Je crois que le lien suivant serait utile pour comprendre l'architecture fsfs
http://svn.Apache.org/repos/asf/Subversion/trunk/Subversion/libsvn_fs_fs/structure
Depuis le document Subversion Design (qui est assez daté, cependant), vous pouvez obtenir ceci:
Comme de nombreux autres systèmes de contrôle de révision, Subversion stocke les modifications sous forme de différences. Il ne fait pas de copies complètes des nœuds; au lieu de cela, il stocke la dernière révision sous forme de texte intégral, et les révisions précédentes comme une succession de différences inverses (le mot "diff" est utilisé librement ici - pour les fichiers, cela signifie vdeltas, pour les répertoires, cela signifie un format qui exprime les modifications apportées à répertoires).
Je ne pense pas que cela ait changé depuis.
Voir aussi Bubble-Up Method .
la spécification régulière FSFS pourrait vous aider.
Ou si vous utilisez Berkeley DB, voici la spécification pour cela.
FSFS utilise des deltas inverses pour stocker les modifications et skip-deltas pour accélérer certaines actions, si j'ai tout compris correctement.
Chaque fois que vous validez une modification, le référentiel stocke une nouvelle révision de cette arborescence de référentiel globale et étiquette la nouvelle arborescence avec un nouveau numéro de révision. Bien sûr, la plupart de l'arborescence est la même que la révision précédente, à l'exception des parties que vous avez modifiées.
Le nouveau numéro de révision est une étiquette séquentielle qui s'applique à toute la nouvelle arborescence, pas seulement aux fichiers et répertoires que vous avez touchés dans cette révision. Cependant, familièrement, un numéro de révision est utilisé pour faire référence au changement validé dans cette révision; par exemple, "le changement dans r588" ("r588" est un raccourci pour "révision 588") signifie vraiment "la différence entre les arbres de référentiel 587 et 588", ou en d'autres termes, "le changement apporté à l'arbre 587 pour produire l'arbre 588 ".
Jetez un œil à: FAQ Subversion