estimer directement la taille d'une année est évidemment impossible, sauf si vous avez une idée du nombre de livraisons et la taille finale de l'arbre de travail.
Cela dit, git est plutôt efficace sur le plan de l'espace disque. Il ne stocke absolument jamais plus d'une copie d'une version donnée d'un fichier (ceci est représenté en interne comme un blob), et les blobs plus anciens sont compressés en delta en paquets. Cela signifie qu'il est très efficace pour stocker du texte brut et très inefficace avec de gros fichiers binaires. Si votre projet est majoritairement en texte brut, vous n'avez presque rien à craindre.
Les branches et les étiquettes n'ont essentiellement aucun effet sur la taille. Bien sûr, le reflet d'une branche peut atteindre quelques Ko, mais ce n'est pas grave. Les balises légères sont quasiment des SHA1 stockées, et les balises annotées ajoutent juste un tout petit peu de métadonnées. En ce qui concerne les lignes de code et le nombre de commits, il est difficile de dire exactement. Généralement les commits sont un facteur beaucoup plus grand que les lignes de code; vous pouvez avoir beaucoup de nombreuses versions de fichiers tout en ajoutant (même représenté sous forme de deltas), mais le contenu réel doit seulement être stocké une fois. Ceci est sauvegardé par le fait que les arbres de travail ont tendance à être beaucoup plus que le répertoire .git. Par exemple, mon clone de git.git a une arborescence de travail de 17 Mo et un répertoire .git de 39 Mo. Les autres projets que j'ai examinés ont des ratios similaires.
Plus commets de taille égale augmenterait certainement le dépôt, mais en prenant 1000 validations et en les divisant en 10000 (englobant les mêmes changements) ne ferait pas le dépôt beaucoup plus grand. Les objets commit eux-mêmes sont petits; ce sont les différences dans les fichiers qui prennent de l'espace. Vous pourriez voir un pic initial de taille, car les commits ne sont que périodiquement compressés en delta, mais une fois que git gc --auto est déclenché, ces commits seront de nouveau compressés.
La meilleure généralisation que je peux faire est que tend le répertoire .git d'un référentiel croître à un taux proportionnel à la quantité de delta par temps, ce qui en général devrait être proportionnelle à la taille de l'arbre de travail et le taux auquel les gens modifient le projet. Ceci est bien sûr si général qu'il est complètement inutile, mais vous y êtes.
Si vous voulez estimer, je prendrais juste quelques données au cours du premier mois, et j'essaierais d'ajuster une courbe.
Cela devrait vraiment être deux questions - l'une sur git et l'autre sur mercurial. Bien sûr, ils sont tous deux DVCS, mais ils ne sont pas les mêmes. Ils n'ont pas les mêmes internes, et ils ne vont pas se comporter de manière complètement identique. – Cascabel
@Jefromi: Ils utilisent tous deux la deltaification, ils stockent tous deux des versions complètes tous les N deltas, ils compressent les deltas et les versions complètes. –
@Jakub: assez bien. Je n'étais pas totalement confiant à propos de mercurial, je savais juste que c'était similaire. Bien sûr, étant donné que la question a été posée, le PO ne la connaissait presque certainement pas. (Et même si la réponse est la même pour les deux, un instinct à moi les veut toujours en tant que questions séparées, semble plus propre, d'autant plus qu'il y a des réponses séparées sur git et mercurial.) Qui accepter?) – Cascabel