TFS Branching et espace disque

Question

J'ai réfléchi sur des stratégies (créant des branches ramifiées par fonction, peut-être par développeur puisque nous sommes un petit groupe) et je me demandais si quelqu'un avait connu des problèmes. Est-ce que la création d'une branche prend beaucoup de place?

Answer 1

La dernière fois que je regardais, TFS utilise copy-on-write, ce qui signifie que vous ne serez pas augmenter l'espace disque jusqu'à ce que vous modifiez les fichiers. Il est un peu comme l'utilisation de liens symboliques jusqu'à ce que vous avez besoin de changer les choses.

Answer 2

James est fondamentalement correcte. Pour une réponse plus complète, nous devons commencer par le poste de Buck de retour en 2006: http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx

  

Chaque nouvelle ligne dans la table de la version locale ajoute environ 520 octets (une ligne est ajoutée pour chaque espace de travail qui obtient l'élément nouvellement ajouté, et la taille est dominée par la colonne de chemin local). Si vous avez 100 espaces de travail qui obtiennent l'élément nouvellement ajouté, la base de données augmentera de 52 Ko. Si vous ajoutez 1000 nouveaux fichiers de taille moyenne (mélange de fichiers source, binaires, images, etc.) et ont 100 espaces de travail à obtenir, la base de données de contrôle de version augmente d'environ 112 Mo (60 Ko * 1000 + 520 * 1000 * 100) .

On peut omettre le chiffre 60KB puisque les éléments ramifiés ne fassent pas double emploi contenu du fichier. (Il est pas tout à fait « copy-on-write, » James - un O (N) quantité de métadonnées doivent être calculées et stockées pendant l'opération de la branche elle-même, contre des systèmes tels que git que je crois branche en O (1) - mais vous avez raison que le nouvel élément pointe vers le même enregistrement dans tbl_Content que l'élément source jusqu'à ce qu'il soit modifié). Cela nous laisse simplement le facteur de 520 * num_workspaces * files_per_workspace. Sur le serveur MS dogfood il y a quelque chose comme 2 milliards de lignes tbl_LocalVersion, mais dans un petit groupe décrit auto-il devrait être tout à fait négligeable.

Quelque chose le blog de Buck ne mentionne pas est la fusion de l'histoire. Si vous adoptez une branche lourde flux de travail et de s'y tenir à travers plusieurs cycles de développement, il est probable tbl_MergeHistory se développera presque aussi grand que tbl_LocalVersion. Encore une fois, je doute qu'il va même vous inscrire sur le radar d'une petite équipe, mais sur de grandes installations, vous pouvez facilement accumuler des centaines de millions de lignes. Cela dit, chaque ligne est beaucoup plus petit car il n'y a pas nvarchar (260) champs.