J'utilise les versions Application sur un Mac pour gérer un référentiel SVN pour mes fichiers. Ma copie de travail est d'environ 6 Mo, mais mon référentiel n'est que de 1,4 Mo et je tiens cinq révisions dans le référentiel!
Comment cela peut-il être?
4 Réponses :
SVN compresse une version de votre code les différences entre chaque version. C'est pourquoi cela ne prend pas beaucoup d'espace.
garder le référentiel petit, Subversion utilise la délicatesse (ou stockage délivré) dans le référentiel lui-même. Délicatesse implique de coder la représentation d'un morceau de données comme une collection de Différences contre un autre morceau des données. Si les deux données sont très similaire, cette délicatesse entraîne des économies de stockage pour la chunk délié plutôt que de prendre espace égal à la taille de la données originales, il ne suffit que suffisamment Espace pour dire: "Je ressemble à ça Autre morceau de données ici, sauf pour le couple suivant de changements. " Le résultat est que la plupart des données de référentiel qui tend à être volumineux-nommément, le contenu de Les fichiers versionnés - sont stockés beaucoup taille plus petite que l'original représentation du texte intégral de ces données. Et pour les référentiels créés avec Subversion 1.4 ou ultérieure, l'espace les économies sont encore meilleures-maintenant celles Représentations de texte intégral du fichier Les contenus sont eux-mêmes comprimés.
Plus de détails peut être trouvé ici
Votre copie de travail contient normalement beaucoup de fichiers temporaires supplémentaires tels que le code d'objet et les en-têtes précompilés qui ne sont pas tenus de révision contrôlées. Je suppose que si vous nettoyez la copie de travail ou si vous faites une nouvelle caisse, ce sera beaucoup plus petit.
Ceci est vrai, mais pour les raisons expliquées par Nawaman et WCoenen, même une copie de travail propre nouvellement choisie avec aucun fichier généré (telle que les en-têtes précompilés et le code d'objet) peut être significativement plus grande que le référentiel: la copie de travail a deux copies de Chaque fichier non compressé (fonctionnel et vierge), tandis que le référentiel dispose d'une copie compressée de chaque fichier + Deltafied modifications (qui peut être très faible si les modifications ont été localisées).
Voici quelques raisons pour lesquelles je peux penser à - SVN stocke vos révisions comme des modifications et non des fichiers versionnés. - SVN stocke les données dans son backend (FSF / BDB) qui comporte certaines techniques de compression qui réduisent la taille. Si le référentiel dispose de davantage de fichiers texte, plus la compression peut donc s'attendre à une diminution drastique de taille. - Pour prendre en charge quelques commandes (comme SVN Info, DIFF, etc.) sans connexion réseau (également avoir des résultats plus rapides) SVN maintient certaines informations supplémentaires dans les DIRS .SVN. Les informations supplémentaires incluent une copie de l'ensemble de la copie de travail.
La réponse de Nawaman a déjà expliqué que les données du référentiel sont compactées de manière assez efficace.
L'autre moitié de l'histoire est que Subversion conserve un Pristine Copiez de chaque fichier à l'intérieur du .svn dossiers de votre copie de travail. Cela permet à Subversion de gérer les commandes SVN Status ou SVN DIFF sans avoir besoin de contacter le serveur de référentiel, mais double la taille de votre copie de travail .
La compression pourrait l'expliquer, mais honnêtement, je ne sais pas. 75% de compression n'est pas inouïe du texte pur.
(Remarque, il est en fait d'environ 75% car SVN ne contient que des modifications, pas des copies complètes de chaque révision))