350GB SVN repo créé au moins la révision de 1Mo même pour une tâche simple comme branche / tag

Question

Tout a commencé quand j'ai remarqué que ma taille dépôt augmente à un taux quotidien de 1 Go. Je l'ai fait un test simple. Création d'une branche / étiquette d'un dossier existant qui avait une taille de 35KB. Je pris note du numéro de révision et je suis allé à $REPO/db/revs/<K-rev>/rev-number/ et vérifié la taille de la révision. Il était de 1 méga octet. Cela semble louche. Toutes les idées sur ce qui pourrait être mal ici. Mon repo est d'environ 350 Go en taille, avec environ 600 000 révisions.

P.S. Je l'ai déjà commencé une reconstruction du référentiel entier pour voir si cela fait une différence, mais il faudra probablement des jours.

Answer 1

Publié même question à users@subversion.sapache.org et a obtenu cette réponse de B Smith-Mannschott - ce qui explique tout. J'ai un répertoire dans le chemin qui contient des dossiers 16000 - pour chaque livraison. Merci B Smith-Mannschott pour la réponse détaillée. réponse de poster ici pour le bénéfice des autres.

---

Votre répertoire contient un répertoire très grand nombre d'entrées? Sont les changements qui produisent les grands commits réalisés dans ou au-dessous, tels un répertoire?

Supposons que de commettre un seul changement à un seul fichier à votre dépôt. Allons plus loin suppose que le fichier se trouve ici, dans votre référentiel:

/project/trunk/some-really-large-directory/notes/blah.txt

Lorsque vous vous engagez le changement à blah.txt, la nouvelle révision réécrira les nœuds de répertoire entre « blah.txt » et la racine du référentiel: / projet / trunk / un-très-grand répertoire / notes, / Projet / trunk / un-très-grand-répertoire, / projet / trunk, / projet, /. Lorsque la réécriture d'un nœud de répertoire, FSFS toujours stocke la nouvelle version dans son intégralité. (Ceci est différent de la façon dont les changements aux fichiers sont stockés, qui sont généralement des différences à une version précédente de le même fichier.)

Si / projet / trunk / un-très-grand répertoire / contient, par exemple 10000 fichiers, chaque engagent à blah.txt stockera une copie complète de ce répertoire (avec ses noms 10'000) dans votre répertoire.

Je l'ai remarqué quand je commencé à tenir un wiki personnel sous la version le contrôle il y a quelques années. Il était un répertoire plat de plus de 10'000 texte des dossiers. Je me suis vite remarqué que commits étaient assez gros. (Je l'ai depuis commuté à git pour cette tâche, pour cette raison et d'autres.)

voir aussi http: //svn.apache.org/repos/asf/subversion/trunk/notes/subversion-design.html#server.fs.struct.bubble-up

Answer 2

Il y a une solution très simple. En supposant que votre dépôt contient une énorme quantité d'étiquettes historiques, vous pouvez les déplacer vers /tags-archive et rendre ce répertoire en lecture seule. Lorsque vous allez créer de nouvelles étiquettes sous /tags problème, il ne se produira plus.

Notez que vous devez utiliser l'URL pour déplacer URL. Par exemple.

svn move https://svn.example.com/MyRepo/tags https://svn.example.com/MyRepo/tags-archive -m "Your Log Message"

Cette solution a permis de résoudre le problème pour un dépôt qui contenait environ 350.000 balises dans un seul répertoire.