Nuestra empresa está creando una convención de nombres para ramas SVN y etiquetas, y no estoy cómodo con la idea de usar solo la fecha o el número de compilación en las ramas/nombres de las etiquetas.¿Qué convenciones de nomenclatura usa para SVN Branches and Tags?
Creo que necesitamos nombres que aporta una mayor definición de lo que representa este camino, qué esfuerzo se está haciendo, etc.
¿Qué le parece/usar?
Todas nuestras tareas de desarrollador entran en un sistema de seguimiento de errores. Este sistema de seguimiento de errores tiene identificadores asociados con cada tarea.
Así que por el nombre de la sucursal de cualquier tarea, utilizamos:
ticketId_TicketSubject
Cuando una rama contiene múltiples ticketIds que acabamos de combinarlos en el nombre de la sucursal:
ticketId1_ticketId2_Description
De esta forma, si está interesado en un ticket y desea saber qué rama crear, puede buscarlo fácilmente. Del mismo modo, si desea encontrar el boleto con la compilación de sucursal, también puede encontrarlo fácilmente.
Para las etiquetas, las etiquetamos por el número de versión.
En cuanto a la ubicación de cada rama. Tenemos una jerarquía de nivel superior como esto:
/branches
/tags
/trunk
Entonces todos nuestros productos/proyectos van debajo de cada uno de los que están dentro de sus propias subcarpetas.
/trunk/project1/
/branches/project1/TicketId_Description
Para una rama de la característica, nombre que después de lo que se está haciendo. Por ejemplo, moví nuestro ORM de LINQ a SQL a NHibernate y creé una rama llamada "NHibernate". Una vez que haya completado la rama y la haya vuelto a unir al tronco, puede eliminar la rama para guardar conflictos de nombres en el futuro. Si realmente necesita recuperar la rama que puede, solo tiene que profundizar en el historial y restaurarla.
Si tiene números de historia/presupuesto/trabajo que son relevantes para una sucursal, lo anexaría al nombre de la sucursal, por ejemplo. "NHibernate_429" para que pueda referenciarlo fácilmente contra su sistema de seguimiento. Sin embargo, siempre elegiría primero el inglés ya que es a lo que la gente se referirá más realista cuando esté en desarrollo.
Para cosas como las etiquetas, es difícil decir lo que quieres hacer ya que depende de lo que estás etiquetando. Si está etiquetando lanzamientos, entonces usaría "Release X.X.X.X "o algo simple como eso. Realmente no le va a importar cuál es la fecha o el número de compilación cuando está buscando un lanzamiento específico como ejemplo.
Lo que usamos (principalmente siguiendo la convención aceptada) :
projectName
|
--trunk
|
--tags
|
--branches
Bajo tronco que tienen el tronco principal
En etiquetas de etiquetamos cada lanzamiento (ambos, de prueba comunicados internos y comunicados de los clientes) No sólo tiene que utilizar el número de versión que el nombre de la etiqueta
...Bajo las sucursales tenemos o ne rama para cada versión principal que lanzamos (en nuestro caso, el resultado de una iteración XP). Esos son nombrados como la versión principal ("v5.03", "v6.04"). Además, tenemos sucursales internas para cambios importantes o versiones especiales. El nombre es de forma libre, y se supone que el nombre le dice a la gente qué representa la rama. Las extensiones serían "workaround_customerA", "module_x_reorg", etc.
Le damos a nuestras sucursales una versión ".X", donde las etiquetas tienen un número.
Por ejemplo, la rama sería Foo-1.2.3.X, y las etiquetas sería Foo-1.2.3.1, 1.2.3.2-Foo, etc.
También tenemos una etiqueta especial, Foo -1.2.3.0, que se crea tan pronto como se crea la rama desde el tronco, antes de cualquier cambio. Eso es para que podamos dividir las ramas y las etiquetas en el estado inicial en cualquier momento (ya que en un par de días, es probable que el tronco sea diferente). Esta práctica ha hecho que las fusiones sean un poco más fáciles, y hace que descubrir qué código ha cambiado en la rama sea mucho más fácil.
siempre me prefijo de las etiquetas (y por lo general ramas también) con la fecha en formato AAAAMMDD, seguida de una descripción del propósito de la etiqueta o de la rama.
por ejemplo, 20090326_Release_v6.5 o 20090326_Post_Production_Update
Esto está bajo el tronco/tags/ramas jerarquía estándar por supuesto.
La fecha de prefijo se asegura de que todas las etiquetas o las ramas se muestran en orden de creación, que es mucho más útil a continuación, sólo ser ordenadas según la descripción si su exploración a través de una gran carpeta de etiquetas. Verá la línea de tiempo de cuándo y por qué se crearon (como mensajes de mini log).
El uso de etiquetas como un mecanismo para rastrear la información para la que está destinado un sistema de seguimiento de errores parece contrario a la intuición. Casi exclusivamente, lo único que he visto es usar un número de versión en la etiqueta. Ese número de versión se correlaciona con el lanzamiento del sistema de seguimiento de errores, que luego tiene todos los detalles que necesita. –
Bueno, ramificación es más o menos abierta, ya que hay diferentes tipos de ramas, el nombramiento de ellos puede ser muy diferente.
Vale la pena recordar qué control de fuente le brinda. Los nombres de etiqueta no son solo "v1.4", es "/CashCowProject/tags/v1.4". Nombrar una etiqueta "/CashCowProject/tags/CashCowProject-v1.4" es un poco redundante, ¿qué más sería?
El control de revisión también le da acceso total a las fechas y horas en que se crearon las etiquetas. El control de revisión también le proporciona mensajes de compromiso que debería utilizar, en particular la primera línea.
Teniendo en cuenta toda esta información, no es difícil de lograr en conjunto una visión simple que le da toda la información que necesita, procedente de fuentes consistentes y apropiadas, tales como:
CashCowProject
v1.4 - 26 March 2009 : With Added whizzbang (more)
v1.3 - 13 February 2009 : Best graphics! (more)
v1.2 - 01 January 2009 : Upgraded security (more)
La única cosa que el nombre de la etiqueta es realmente útil porque aquí está el número de versión.Si tratas de poner toda la información en un nombre de etiqueta, es un poco prolijo y apuesto a que no se verá tan bien.
Dicho esto, sigo nombrando mis etiquetas "Proyecto-4.8" –
Creo que este pensamiento funciona bien para las etiquetas, pero no necesariamente para las ramas. Puedo abrir una rama experimental, y un número no me dirá nada sobre de qué se trata esta rama. –
De hecho, estoy dejando completamente el nombre de la rama de esta respuesta, y un número no sería un buen nombre de sucursal. –
Mejor:
<projectname>_<Year>_<minor>_00
como:
XYZ_14_01_00
Me gustaría extender la pregunta para preguntar qué convención de nombres se puede utilizar para diferenciar las ramas experimentales (grandes cambios de ruptura para fusionar más adelante) desde sucursales que se crean para mantener versiones anteriores. Tal vez haya incluso más "tipos" de ramificación. – SandRock