Uso adecuado de etiquetas en SCM

Question

Mis compañeros de trabajo y yo estamos discutiendo sobre el valor y el uso de etiquetas en los sistemas de lanzamiento/SCM.Esperamos que la comunidad de StackOverflow exprese sus opiniones para ayudarnos a resolver el problema.

Un lado afirma que las etiquetas son una valiosa adición a la gestión de versiones.Un ejemplo de su uso:Hacemos una versión de Maven, que crea una nueva etiqueta (llámela 1.0), que es una instantánea del código utilizada para esta versión.Esta etiqueta debe ser una rama READONLY.Cuando es necesario corregir un error, podemos hacer una copia de la etiqueta en una nueva rama (llámela 1.1).Las correcciones de errores van allí.Estas correcciones se pueden fusionar nuevamente en Trunk para que la rama de desarrollo principal obtenga las correcciones de errores.Finalmente, se lanza 1.1 y se crea automáticamente una Etiqueta 1.1.Este ciclo continúa.El principal beneficio aquí de la Etiqueta es que si alguna vez necesita volver a publicar la versión 1.0 por cualquier motivo, puede simplemente publicar la Etiqueta 1.0 con la confianza de que nadie la habrá modificado.Además, decir "Etiqueta de lanzamiento 1.0" es más limpio que decir "Revisión de lanzamiento 1 de la rama 1.0, que es la 1.0 original sin las correcciones".

La otra parte afirma que las etiquetas no brindan ningún beneficio valioso, especialmente en un sistema como Subversion con revisiones globales, que actúan como una etiqueta en CVS.Además, Subversion sólo da una advertencia cuando se compromete con una etiqueta;en realidad no lo detiene.Su método se desarrolla en Trunk y, una vez lanzado, crearías una rama llamada 1.0.Continuaría corrigiendo errores en Trunk y si necesitara volver a publicar esas correcciones de errores en producción, las fusionaría en la rama 1.0 y volvería a publicar 1.0.En algún momento, tal vez después de correcciones o características importantes en Trunk, lanzarías y crearías Branch 1.1.El ciclo continúa.Si alguna vez necesita lanzar la versión 1.0 original, deberá consultar la revisión 1 de la rama 1.0.

Es evidente que ambos métodos funcionan.Me gustaría escuchar la opinión de la comunidad sobre qué método se prefiere y por qué.

Editar:Me preocupa un poco que la "mejor" forma dependa del sistema SCM subyacente.O opte por Subversion para obtener respuestas o, si es posible, manténgalo independiente de SCM.

Answer 1

Desde un punto de vista agnóstico de SCM, un etiqueta es muy diferente de una revisión.

Ambos pueden implementarse de la misma manera, ambos representan una "línea de tiempo", pero su objetivo es diferente:

• una etiqueta representa un inmutable Estado donde todos los archivos están referenciados por una identificación única.es un nombre representando muchas cosas pero principalmente un estado estable, ...)
• una revisión representa una transacción de confirmación (no todos los SCM tienen esos, especialmente los antiguos con un 'enfoque archivo por archivo').Todas las confirmaciones no representan un estado "estable" (como en "compilar" o "ejecutar" correctamente).Son sólo un nuevo elemento de la historia global.

El problema con SVN es que la revisión, la etiqueta y las ramas se implementan de la misma manera.
Pero aún así preferiría la opción donde se usa una etiqueta como rama "solo lectura".

Answer 2

En mis etiquetas de opinión son útiles. Habrá momentos en algún momento de la vida del proyecto que se encuentra con un error o un cambio y le gustaría saber si estaba allí en una versión anterior. Habrá razones para comparar el código de una versión a otra para medir la eficiencia tanto en el rendimiento y en realidad el desarrollo del código.

Por supuesto, existe la posibilidad de que pueda meter la pata, pero siempre se puede deshacer. Realmente no hay razón para no hacerlo, y hay varias razones por las que podría ser útil en el futuro. me es una obviedad.

Estoy de acuerdo que también se debe utilizar ramas y haciendo su desarrollo allí, pero en cualquier momento que realmente soltar algo, hacer una etiqueta fuera de él.

Answer 3

Sí, desea utilizar las etiquetas.

Piense en una etiqueta como se acaba de una etiqueta o un nombre para una revisión en particular. Es muy útil en mi experiencia para marcar hitos importantes en un proyecto, ya sea para la versión de producción o incluso para las versiones provisionales de control de calidad. A menudo querrá volver atrás en el tiempo y ver el código fuente de una versión particular.

Si se ramifican después de la liberación, siempre se puede averiguar qué revisión fue lanzado a la producción, pero esto es una especie de dolor en comparación con sólo mirar a una etiqueta. Si no se utiliza ramas de liberación, entonces será fácil perder la pista de los cuales se utilizó la revisión para crear una versión en particular.

El problema con SVN es que se difumina la distinción entre etiquetas y ramas. Cualquier persona siempre puede comprometerse a una etiqueta, por lo que no está garantizado para ser fijada / inmutable. En otras VCS como PVCS, una "etiqueta" es inmutable. Puede adoptar una convención equipo para evitar que compromete a las etiquetas, o incluso tal vez usar cometer ganchos para evitar que compromete a las etiquetas.

Answer 4

Utilizamos tags (etiquetas) cuando se crean nuevas líneas de base. Lo hacemos una vez por semana, pero algunos equipos lo hacemos, incluso varias veces al día.

El punto (para nosotros) siempre es asegurarse de que la nueva línea de base es estable: por lo que no es sólo una construcción, es una construcción que pasa todo el banco de pruebas, varias horas de pruebas automatizadas, además de los exploratorios potencialmente manuales también

A continuación, la línea de base se utiliza como punto de partida para todas las tareas durante la siguiente iteración: cada nueva tarea es una nueva rama a partir de la línea de base, que se sabe que es estable por lo que todo lo que está roto en la tarea debe ser fácil de rastrear en el interior la tarea en sí.

Normalmente sólo nos ponemos etiquetas (etiquetas) en la rama principal (o el tronco principal o en función de su sabor SMC), que es el punto de integración para todas las otras ramas.

Cuando liberamos un producto oficial creamos una "rama de lanzamiento para que" por lo que sólo recibirá correcciones mientras que el nuevo desarrollo se queda en "principal". A continuación, estas "ramas" de mantenimiento (esperemos que sólo uno o dos a la vez) se pueden etiquetar también.

Answer 5

Me gusta pensar acerca de las etiquetas como "sólo un nombre elegante para una revisión". Siempre he pensado de esa manera, y en IIRC mercurial son sólo eso. En la subversión sin embargo, como usted dice, que de hecho son copias (baratos) de tronco / * a las etiquetas / de fantasía-Nombre /

Sinceramente, me gustaría combinar las dos estrategias para obtener resultados óptimos: la etiqueta y la rama después de la liberación. Su etiqueta se llama 1.0.0, rama 1.0-MANT. Corrección de errores van en ramas, y libera de corrección de errores son etiquetas de nuevo (1.0.1 podrá, mediante una etiqueta destinada a alias 1,0-MAINT en un cierto punto.)

No se olvide sin embargo, que las etiquetas y ramas en la subversión son realmente la misma cosa: copias baratas. La única diferencia entre ellos es la semántica usted / su equipo les atribuye, por lo que prácticamente se reduce a hacer que la gente a ponerse de acuerdo sobre un método particualr y se adhieren a que (podría ser ejecutada en el servidor, por ejemplo, no permitir comete en las etiquetas / excepto para los coordinadores de liberación, etc.).

El problema que veo, aunque con el segundo enfoque es: ¿cómo se va a hacer una distinción fácil entre el software en el campo si se vuelve a la versión 1.0? Eso significa que usted puede tener un 1.0 y 1.0 otra realidad hace referencia a una base de código diferente ....

Answer 6

instantáneas inmutables de código fuente de un proyecto (y ejecutable) son de gran valor para hacer las pruebas de cualquier tipo, ya sea estructurada o campo de pruebas de uso. Para la prueba estructurada, que va a ser la creación de datos que pueden ser referenciados meses o años en el futuro. Cada vez que vuelva a visitar esos datos, la ley de Murphy dice que necesita saber qué código se trata de ya no ser que se tomó la molestia de citar una instantánea particular del código fuente, será imposible saber con seguridad qué código fuente correspondió a que los datos de prueba.

No puedo decirle cuántas veces alguien ha venido a mí y dijo: "Este código microcontrolador no está funcionando, puede ayudar?" y yo les pregunto: "¿Qué versión está usando?" y dicen "no estoy seguro", ya que no están haciendo una buena gestión de liberación (al menos poner una pegatina en el dispositivo, mejor poner información en la EEPROM que se puede consultar en tiempo real de versiones). >: (

Answer 7

En SVN, la diferencia técnica entre el uso de una etiqueta y el seguimiento de la revisión es nula. Me encuentro minimizar el uso de etiquetas en función de cómo la aplicación de SVN es simplemente una copia barata y estorba hasta su "espacio estructura".

La diferencia real viene cuando comunicación una línea de base particular a un gran equipo de desarrolladores. el seguimiento de revisiones lleva una capa adicional de abstracción que puede llegar a ser una fuente de errores. Y como todos somos conscientes, cuando se trata con más de 50 desarrolladores, cualquier fuente de error se convertirá en un área de confusión y pérdida de tiempo. Una etiqueta detallado puede eliminar esa confusión y eliminar cualquier duda en cuanto a lo que el propósito de una línea de base es.

Answer 8

Me combinar ambos enfoques. Siempre que se realice un comunicado, etiquetarlo. Etiquetas deben nunca cambian, por lo que la presencia de una etiqueta "1.0.0" es un indicador de que no se debe tratar de liberar todo lo demás como 1.0.0.

Al mismo tiempo, cuando llegó el momento de hacer 1.0.0, lo pondría en una rama 1.0. Por lo que el flujo es: rama del tronco a 1,0, Etiqueta esta nueva 1.0 como 1.0.0, y desplegar. A continuación, correcciones de errores se pueden hacer en la rama 1.0 (para evitar que se mezclen con cualquier desarrollo 1,1-targetted que puede estar ya en el tronco de ahora) y se fusionaron en el tronco. Cada versión de la fijo 1.0 se etiqueta como 1.0.x de la rama 1.0. Este es básicamente el enfoque que utilizamos en el trabajo con Perforce, y eso es de hecho muy similar a la subversión. (La lectura de las respuestas, creo que es prácticamente idéntica a la recomendación de Vincent)

En cuanto al comentario sobre las etiquetas de ser redundante porque tiene números de revisión --- eso es cierto en gran medida, excepto que también códigos especifican un ámbito de aplicación: es decir, qué archivos en el repositorio están cubiertos por la etiqueta. Usted puede pedir razonablemente a alguien que mirar /svn/proj1/tag/1.0.0 y que están buscando de inmediato a un espacio de trabajo coherente. Si se les pregunta a mirar a la revisión X, tienen que primer vistazo a la revisión X para ver que estaba cambiando (por ejemplo) / SVN / proj1 / trunk / Makefile y de ahí deducir que / SVN / proj1 / trunk / @ X es lo que debe mirar. ¿Qué pasa si la revisión X archivos en proj1 y Proj2 ha tocado? Que es de mal por supuesto, pero en sentido estricto deben decir / SVN / proj1 / trunk / @ X. ¿Y dónde está la lista de los números de revisión almacena? ¿Cómo sabemos que es la revisión 1.0.0 X? En mi humilde opinión que debería ser posible determinar que sólo desde el repositorio.

En sistemas como Git, etiquetas y ramas siguen siendo básicamente la misma cosa (sólo referencias a la base de datos de objetos), pero el convención es que los árbitros de etiquetas no cambian, y los árbitros hacen rama ( y preferiblemente con una restricción específica sobre cómo cambian). Forzosamente también tiene "etiquetas", que son formas de agrupar un conjunto de revisiones de archivos juntos independientemente de una lista de cambios; que es esencialmente una etiqueta, pero más confuso: los números de listas de cambios que hemos utilizado históricamente (equivalentes a los números de revisión de Subversion) calificadas con el nombre de la rama que deberían estar en identificar versiones. Los dos son casi idénticas de cualquier manera, por lo que supongo que aquí TMTOWTDI.