2009-10-06 48 views
11

He estado pensando en algunas estrategias de ramificación (creando ramas por función, tal vez por desarrollador, ya que somos un grupo pequeño) y me preguntaba si alguien había tenido algún problema. ¿La creación de una rama ocupa mucho espacio?TFS Branching and Disk Space

Respuesta

13

La última vez que miré, TFS usa copy-on-write, lo que significa que no aumentará el espacio en disco hasta que cambie los archivos. Es como usar enlaces simbólicos hasta que necesites cambiar las cosas.

+1

+1: Mi comprensión también. La sucursal ocupará espacio en su estación de trabajo local, pero siempre puede ocultar la sucursal si no desea verla (que básicamente la elimina de su área de trabajo) y podarla una vez que esté hecha y fusionada de nuevo. – TrueWill

+0

I No pude encontrar ninguna información sobre esto, así que si alguien encuentra algún enlace, póngalo en su lugar. Gracias por la respuesta. –

5

James es básicamente correcto. Para una respuesta más completa, tenemos que empezar con el poste de Buck de nuevo en 2006: http://blogs.msdn.com/buckh/archive/2006/02/22/tfs_size_estimation.aspx

Cada nueva fila en la tabla de la versión local añade alrededor de 520 bytes (una fila se agrega para cada área de trabajo que recibe el recién agregado elemento, y el tamaño está dominado por la columna de ruta local). Si tiene 100 espacios de trabajo que obtienen el elemento recién agregado, la base de datos crecerá en 52 KB. Si agrega 1,000 archivos nuevos de tamaño promedio (mezcla de archivos fuente, binarios, imágenes, etc.) y obtiene 100 espacios de trabajo, la base de datos de control de versiones crece aproximadamente 112 MB (60 KB * 1,000 + 520 * 1,000 * 100) .

Podemos omitir la cifra de 60 KB ya que los elementos bifurcados no duplican el contenido del archivo. (No es exactamente "copy-on-write", James: una cantidad O (N) de metadatos debe ser calculada y almacenada durante la operación de la rama, vs sistemas como git, que creo ramificar en O (1) - pero tiene razón en que el nuevo elemento apunta al mismo registro en tbl_Contento como elemento fuente hasta que se edite). Eso nos deja simplemente con el factor 520 * num_workspaces * files_per_workspace. En el servidor dogfood de MS hay algo así como 2 mil millones de filas en tbl_LocalVersion, pero en un grupo pequeño que se describe a sí mismo debería ser completamente insignificante.

El blog de Something Buck no menciona la historia de fusión. Si adopta un flujo de trabajo pesado en sucursal y lo mantiene durante varios ciclos de desarrollo, es probable que tbl_MergeHistory crezca casi tan grande como tbl_LocalVersion. De nuevo, dudo que incluso se registre en el radar de un pequeño equipo, pero en instalaciones grandes puede acumular fácilmente cientos de millones de filas. Dicho esto, cada fila es mucho más pequeña ya que no hay campos nvarchar (260).

Cuestiones relacionadas