Question

Je lis le livre de la subversion et il est clair pour moi que la subversion ne stocke pas les fichiers individuels, mais seulement deltas afin de minimiser l'espace disque. Subversion fait aussi la même chose avec les fichiers binaires ainsi (ce qui était autrefois une énorme faiblesse de CVS).

Cependant, je ne comprends pas le mécanisme exact. Lorsque je commets un fichier ce qui se passe?

  1. Subversion stocke seulement les diff (et a déjà l'ancienne version)
  2. Subversion supprime la version précédente, stocke le nouveau fichier intact et crée une diff inverse afin de « recréer » l'ancienne version si nécessaire.
  3. Quelque chose d'autre que je ne l'ai pas pensé.

Le premier cas peut sembler le plus logique. Cela soulève toutefois une autre question. Si j'ai dans un dépôt subversion d'un fichier avec 1000 commits et un nouveau développeur vérifie une copie propre, puis la subversion devrait chercher la version d'origine (importation initiale) et appliquer 1000 diffs sur ce avant de retourner le résultat. Est-ce correct? Y at-il une sorte de mise en cache des fichiers où la dernière version est maintenue aussi bien?

Au fond où puis-je trouver des informations sur le fonctionnement interne du référentiel svn?

Mise à jour: Apparemment, le back-end de la subversion joue un grand rôle dans ce domaine. À l'époque ou l'écriture FSFS utilise l'option 1 tandis que BDB utilise l'option 2. Merci msemack!

Était-ce utile?

La solution

Parce que le format de dépôt de Subversion est entièrement interne, ils sont libres de changer la représentation d'une révision à l'autre. Je crois que la révision en cours stocke généralement deltas inverse (votre option 2), mais aussi stocke des instantanés complets périodiquement de sorte qu'il n'a pas à résoudre 1000 diffs avant de retourner un résultat.

Les Subversion 1.6 notes de version a une section sur les améliorations de stockage systèmes de fichiers qui a des notes à ce sujet, et des liens vers d'autres sources. Autant dire que les détails de stockage de données de Subversion sont complexes et sujettes à changement.

Il y a aussi un document de conception dans l'arbre source de Subversion qui décrit l'utilisation de sauter deltas dans Subversion . En général, le répertoire / notes / contient plusieurs documents utiles concernant Subversion internes .

Autres conseils

Je crois que le lien suivant serait utile pour comprendre l'architecture fsfs

http://svn.apache.org/repos/ asf / subversion / tronc / subversion / libsvn_fs_fs / structure

la spécification régulière FSFS peut vous aider .

Ou si vous utilisez Berkeley DB, est ici la spécification pour cela.

FSFS utilise deltas inverse pour enregistrer les modifications et SKIP- deltas pour accélérer certaines actions, si je comprends tout correctement.

  

Chaque fois que vous livrez un changement, la   référentiel stocke une nouvelle révision de   cet arbre global de dépôt, et   Libelle le nouvel arbre avec une nouvelle   numéro de révision. Bien sûr, la plupart des   l'arbre est le même que la révision   avant, sauf pour les pièces que vous   changé.

     

Le nouveau numéro de révision est   étiquette séquentielle qui applique à la   tout le nouvel arbre, non seulement aux fichiers   et les répertoires que vous avez touché dans ce   révision. Cependant, familièrement, un   numéro de révision est utilisé pour désigner   le changement engagé dans cette révision;   par exemple, « le changement de r588 »   ( « R588 » est un raccourci pour « révision   588" ) signifie vraiment « la différence   entre les arbres de dépôt 587 et 588" ,   ou en d'autres termes, « le changement a   à l'arbre pour produire 587 588" arbre.

Jetez un oeil à: Subversion FAQ

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top