TFS ramas y espacio en disco

Question

He estado pensando sobre algunas estrategias de ramificación (creando ramas por función, tal vez por desarrollador ya que somos un pequeño grupo) y se preguntaba si alguien había experimentado ningún problema. No crear una rama ocupa mucho espacio?

Answer 1

La última vez que miré, TFS utiliza copia en escritura, lo que significa que no va a aumentar el espacio de disco hasta que cambie archivos. Es algo así como el uso de enlaces simbólicos hasta que tenga que cambiar las cosas.

Answer 2

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 espacio de trabajo que recibe el elemento recién añadido, y el tamaño está dominado por la columna de la ruta local). Si usted tiene 100 espacios de trabajo que consigue el artículo que acaba de agregar, la base de datos crecerá un 52 KB. Si añade 1.000 nuevos archivos de tamaño medio (mezcla de archivos de código fuente, binarios, imágenes, etc.) y tiene 100 espacios de trabajo conseguir que, la base de datos de control de versiones crece en aproximadamente 112 MB (60 KB * 1000 + 520 * 1000 * 100) .

Podemos omitir la cifra de 60 KB desde artículos ramificados no duplican el contenido del archivo. (No es exactamente "copia en escritura", James - un O (N) cantidad de metadatos debe ser calculado y almacenado durante la propia operación de salida, frente a los sistemas como Git que creo sucursal en O (1) - pero estás en lo correcto de que el nuevo elemento apunta al mismo registro en tbl_Content como el elemento de origen hasta que se editó). Eso nos deja con sólo el factor 520 * num_workspaces * files_per_workspace. En el servidor de MS comida para perros que hay algo así como 2 mil millones de filas en tbl_LocalVersion, pero en un grupo pequeño describe a sí mismo que debe ser completamente insignificante.

el blog

Algo de Buck no menciona es la fusión de historiales. Si usted adopta un flujo de trabajo de rama pesada y se pega con él a través de varios ciclos de desarrollo, lo más probable es tbl_MergeHistory crecerá casi tan grande como tbl_LocalVersion. Una vez más, dudo que siquiera registrarse en el radar de un pequeño equipo, pero en grandes instalaciones se puede acumular fácilmente cientos de millones de filas. Dicho esto, cada fila es mucho menor ya que no existen (260) campos nvarchar.