TFS: etiquetas vs conjuntos de cambios
label changeset (4)
Estoy tratando de encontrar las mejores prácticas con respecto al uso del control de fuente TFS. En este momento, cada vez que hacemos una compilación, etiquetamos los archivos que se registran en el TFS con el número de versión. ¿Es este enfoque mejor o peor que simplemente verificar los archivos y tener el número de versión en los comentarios? ¿Puedes usar el conjunto de cambios para volver si es necesario o las etiquetas son aún más versátiles?
¡Gracias!
En este momento, cada vez que hacemos una compilación, etiquetamos los archivos que se registran en el TFS con el número de versión
No necesitas hacer esto. TFS puede referirse a un estado de la base de código de muchas maneras, de las cuales las etiquetas son de hecho una, pero también lo son las construcciones e incluso los conjuntos de cambios. Puede ver las formas disponibles de reconstruir un punto particular en el tiempo haciendo una Get Specific Version... y examinando las opciones en el menú desplegable Type :
Changeset
Date
Label
Latest Version
Workspace Version
Changeset permite obtener justo después de cualquier conjunto de cambios; Date es obvia; Label también lo es, excepto que las compilaciones * crean automáticamente etiquetas (elija Label en este menú desplegable y luego eche un vistazo al diálogo Find Label ).
* ¡Creo que es automático! A menos que sea algo que hemos establecido especialmente donde estoy en este momento ...
Debe etiquetar las versiones de los archivos fuente que componen su compilación. Si usa TeamBuild, lo hace automáticamente. Combina el nombre de la definición de tu construcción, la fecha y el número de compilación. Entonces no necesitas hacer nada.
Su otra opción no es muy convencional y requiere mucho trabajo innecesario. Si lo entiendo correctamente, verificaría sus archivos fuente durante el proceso de compilación y luego los verificaría con un número de versión especificado en los comentarios del check-in. Esto es lo que Alex mencionó como un recurso muy intensivo en términos de su proceso de compilación y también su repositorio de control de origen. Además, ¿cómo obtendría los archivos de origen para una versión particular si la información de la versión está incorporada en los comentarios? Será muy difícil y tendrá que sentarse y escribir su propia aplicación que utiliza la API de control de fuente TFS para descargar los archivos de origen a un área de trabajo buscando el número de versión en los comentarios de check-in. Esto crea una complejidad innecesaria y dolores de cabeza.
Si usa etiquetas en su lugar, puede hacer una etiqueta de obtención en VS IDE para descargar los archivos fuente que componen esa etiqueta. Incluso puede decirle a TeamBuild que use una etiqueta en lugar de descargar los últimos archivos fuente durante la automatización de compilación. De esta forma, puede crear versiones anteriores de su aplicación fácilmente. Con las etiquetas, también puede aplicar conjuntos de cambios posteriores a una etiqueta existente si hubo cambios de código simplemente obteniendo esa etiqueta y luego obteniendo conjuntos de cambios específicos y luego haciendo una etiqueta rápida o creando una etiqueta nueva.
El etiquetado es muy potente, cómodo de usar y forma parte de TFS. En lugar de idear una solución personalizada que requiera un gran esfuerzo para que funcione y se mantenga, solo intente utilizar lo que ya está disponible.
no me permitirá comentar las respuestas anteriores, así que estoy escribiendo esto como una nueva "respuesta". Quiero aclarar algunos de los conceptos erróneos enumerados anteriormente.
En primer lugar, el uso de etiquetas TFVC requiere MÁS recursos que el uso de conjuntos de cambios. Mucho más. Los comandos como Branch, Merge y Get by Label son más lentos. Para servidores empresariales con enormes bases de datos, no desea utilizar etiquetas.
En segundo lugar, las compilaciones no crean automáticamente etiquetas, aunque los pasos de compilación predeterminados incluyen un paso para crear una etiqueta.
En tercer lugar, como ya se mencionó, las etiquetas se pueden mover o eliminar, por lo que son mucho menos confiables que los conjuntos de cambios que son inmutables.
En general, te recomiendo que NO uses etiquetas. La alternativa más simple es recordar el número de conjunto de cambios para sus compilaciones. O si desea aislar diferentes versiones de lanzamiento, debe crear ramas de publicación.
Las etiquetas están bien para sistemas pequeños, pero no son buenas para grandes empresas.
Tienen dos propósitos diferentes, los ChangeSets son cuando los archivos realmente han cambiado y usted desea mantener un registro permanente de ese cambio. Las etiquetas marcan una cierta versión de los archivos para que pueda volver fácilmente a ese punto. A menos que su compilación realmente cambie los archivos bajo control de fuente y desea registrar estos cambios. Deberías etiquetar.
Además, el etiquetado requiere menos recursos. Y puede tener varias etiquetas en la misma versión de un archivo.