Prácticas estándar para Subversion

Question

Me pregunto si hay otros factores a considerar para la práctica estándar de usar Subversion.

Los pocos que tengo son: Estructura

• Directorio de/tags/tronco y/ramas

• Todo el trabajo se realiza en el tronco, que no se rompe la funcionalidad

• Rama cuando se realizan cambios estructurales importantes o cuando se agrega una función que rompe la funcionalidad principal (sujeto a preferencia)

• Etiquetas contiene versiones estables

• Siempre lleve a cabo una actualización antes de empezar a trabajar

• confirmar los cambios al final del día/cuando una característica se ha agregado

• Commit notas contienen una descripción relevante

• comprometerse basan en función - no cometer manta

Estoy en mentes conflictivas sobre la regla para comprometerme al final del día y cuando se ha agregado una característica. Digo al final del día que el repositorio está lo más actualizado posible. Sin embargo, el código al final del día puede estar incompleto/romper la funcionalidad. Sin embargo, ¿comprometerse solo cuando las características se han completado puede causar desactualizaciones/conflictos?

Agradecería su crítica sobre cualquiera de mis ideas y cualquiera de sus ideas que he perdido.

Gracias!

Answer 1

Siempre debe hacer una actualización antes de comprometerse, para evitar posibles conflictos con otras confirmaciones hechas por otras personas y fusiones dolorosas.

Además, cada confirmación debe contener algo significativo, como una corrección de errores, o una nueva característica, o alguna mejora a una existente, algo que puede ser significativo, descrito en el mensaje de registro. Una herramienta de control de origen no es una herramienta de copia de seguridad, por lo que debe evitarse la realización de "fin de día" sin un contenido significativo.

Answer 2

Si eres nuevo en SVN luego un buen recurso (gratis) es el SVN Book (ejemplares muertos de árboles también se pueden comprar en O'Reilly).

Answer 3

"Sin embargo, ¿comprometerse solo cuando las funciones se han completado puede causar desactualizaciones/conflictos?"

Si el cambio es tan grande que te preocupas por esto, entonces probablemente deberías haber ramificado. Esto le permitiría realizar confirmaciones más pequeñas si realiza un trabajo incremental sin romper la compilación, y dejar un historial claro después de fusionarse en el tronco.

Answer 4

Si una "característica" requerirá algo más que unos pocos (4-6) horas para completar, lo haría bien

• dividen la "característica" en subtareas que se pueden completar en unas pocas horas y comprobadas en el control de fuente
• crear una rama
• tanto de lo anterior

Answer 5

Hay muchas variaciones en relación a los flujos de trabajo de control de código fuente. El que estamos usando es la extensión de lo que está describiendo en su publicación. Su flujo de trabajo es lo suficientemente bueno para modificaciones menores, pero no si tiene varios equipos trabajando en diferentes temas de considerable complejidad.

lo que hacemos es diversificarse para cada equipo, que el equipo puede comprometerse con el equipo de la rama (proyecto). Cada equipo también es responsable de sincronizar la rama del equipo con el troncal mediante la fusión de troncos a ramas, preferiblemente después de cada compromiso con el tronco. Una vez que se completa el proyecto, la rama se fusiona de nuevo en el tronco (se vuelve a integrar) y se elimina.

Este enfoque rama - fusionar ... fusionar - fusionar hacia atrás - eliminar funciona bien para nosotros

Answer 6

que iba a tratar de cometer tan a menudo como sea posible. Para permitir esto, debe asegurarse de que el código que escribe no se haya utilizado aún o que todas las pruebas pasen. Si te mantienes en uno de esos dos modos (este último es mucho mejor que el anterior), entonces no deberías tener que preocuparte por esos períodos largos cuando no puedes comprometerte.

TDD ayuda mucho en este sentido.

Answer 7

Las ramas son una buena idea para hacer grandes cambios, posiblemente de ruptura. Si el tronco se está actualizando al mismo tiempo, ocasionalmente se fusionan de tronco a tronco para mantener actualizada la rama.

Confirmar un conjunto atómico de cambios relacionados. No hagas un gran commit con cambios no relacionados por todas partes. Esto hace que el seguimiento de cambios específicos sea mucho más fácil.

Puede tener varias cajas de la misma fuente - útil si experimentar con cambios no relacionados.

evitar cometer código roto, o el código con las pruebas fallan, o con otras cuestiones pendientes.

Answer 8

Algunas notas más: (han intentado no repetir lo que ya se ha dicho ..)

Ramas:

1. Además de ramificación para los grandes trozos de desarrollo de funciones mencionadas anteriormente, puede ramificarse cuando necesite trabajar en arreglos posteriores a la publicación, mientras el trabajo paralelo progresa en la línea principal/troncal.

2. Fusión inversa regularmente si está utilizando ramas que pueden vivir mucho tiempo sin ser fusionado a la línea principal de desarrollo. Esto ayudará a mantenerse sincronizado con el desarrollo del tronco y minimizar las complicaciones de una fusión Big Bang.

3. Prestar atención a la forma en que lo nombra sus ramas. Intentamos nombrar las ramas después del hito en el que se basa. Ayuda cuando necesita diffs o informes rápidos o incluso mientras busca algo, si los nombres se explican por sí mismos.

4. Dado que en SVN la rama es una copia barata, intentamos siempre ramificar en la raíz del directorio del proyecto (si es la carpeta misma, entonces la rama estará fuera de la línea troncal) - esto evita la confusión posterior sobre que se ramificó y evita tener que ejecutar comandos para descubrirlo. Y si necesita retirar material de una sucursal, todo debajo de la sucursal está disponible para usted, si es que lo necesita.

compromete:

1. voto por compromete a menudo y en trozos lógicos para poder atar los archivos relacionados con un mensaje de registro común. Esto es ideal para cuando quiere un registro y los informes se realizan en fragmentos con todos los archivos relacionados con los comentarios relevantes.

2. He votado por compromisos frecuentes, si no todos los días. Es una forma de pensar. Una vez que vea los beneficios de tener commits tempranos (por supuesto, después de que los desarrolladores hayan comprobado errores de compilación básicos y haya ejecutado pruebas unitarias en su cuadro de desarrollo), le complacería detectar esos problemas tempranos de errores/compilación. Si planea ejecutar compilaciones nocturnas o utilizar una herramienta de integración continua, sería mejor que la gente se comprometa lo antes posible para obtener una idea de las secuencias de trabajo integradas y ejecutar pruebas sobre ellas.

Etiquetas:

1. uñas la liberación convenciones de nomenclatura - aunque esto parece trivial que ayuda a tener buenas nombres de las etiquetas. Asegúrese también de que los comentarios de confirmación de las etiquetas especifiquen exactamente por qué está etiquetando esta versión del repositorio. Solo etiquetamos cuando hacemos compilaciones de hitos, por lo que en nuestro caso, correlacionamos los mensajes de confirmación de etiqueta con el número de compilación continua (etiqueta de compilación de crucero) que estamos utilizando para la construcción dada. También ayuda tener el esquema de numeración de lanzamiento y los campos definidos para que pueda usarlos para las etiquetas.

Answer 9

Recientemente he estado involucrado con la mejora de las técnicas de gestión de configuración de software (SCM) en uso en la empresa para la que trabajo. Descubrimos que tanto la "ramificación para el desarrollo" como la "ramificación para la publicación" funcionan bastante bien.

Un buen libro sobre patrones de SCM/procedimientos estándar que encontré útil es "Patrones de gestión de configuración de software: trabajo en equipo efectivo, integración práctica de Berczuk y Appleton".