Mejores prácticas de SVN: trabajar en equipo

Estoy comenzando con SVN. Conozco los comandos básicos y entiendo los principios básicos. Me preguntaba si alguien tiene algún consejo o mejores prácticas para trabajar con Subversion en un entorno de equipo.

Puedo ver el beneficio de agregar mensajes razonablemente detallados al confirmar el código, pero ¿hay otras cosas que debería tener en cuenta?

Gracias por todas las excelentes respuestas, han ayudado mucho.

Fomenta las confirmaciones frecuentes. Los compañeros de equipo nuevos en el control de versiones pueden sentir que necesitan mantener el código fuera del repositorio hasta que "funcione correctamente". Enseñe a todos a comprometerse temprano y a menudo para encontrar problemas lo antes posible. En lugar de guardar el código hasta que funcione, proponga que sus compañeros de equipo creen ramas para funciones que podrían romper el tronco. Eso lleva a ...

Establezca una práctica de ramificación y etiquetado. Además de las ramas para las funciones, anime a sus compañeros de equipo a usar las ramas para corregir errores importantes. Etiquete las correcciones de errores importantes al principio y al final del trabajo. Mantenga etiquetas (y posiblemente sucursales) para versiones de producción / control de calidad.

Establezca una política para el maletero y cúmplala. Un ejemplo podría ser, "el tronco siempre debe compilarse sin errores". o "el tronco siempre debe pasar todas las pruebas unitarias". Cualquier trabajo que aún no pueda cumplir con los estándares de troncal debe realizarse en una sucursal.

No confirme cambios de formato con cambios de código

Si desea reestructurar el espacio en blanco de un archivo gigante ( Control+ K+ D), está bien. Confirme el cambio de formato por separado del cambio lógico real. Lo mismo ocurre si desea mover funciones en archivos. Confirme el movimiento por separado de la edición real.

Uno de los conceptos clave que siempre sigo es el de realizar juntos los cambios de código relacionados . El corolario es no realizar cambios de código no relacionados en la misma confirmación . Esto significa que no corrija 2 errores en una confirmación (a menos que sea la misma solución) y no cometa la mitad de una corrección de error en cada una de las 2 confirmaciones. Además, si necesito agregar alguna mejora nueva o algo a una parte no relacionada del sistema que luego necesito para algún otro trabajo, realizo la mejora por separado (y primero). La idea es que cualquier cambio que cualquiera pueda querer tener por sí solo (o revertir por sí solo) debería ser una confirmación separada. Le ahorrará toneladas de dolores de cabeza cuando llegue el momento de hacer fusiones o revertir funciones rotas.

Ya se han mencionado muchas cosas, y aquí hay algunas más:

1. Si tiene archivos que no desea en el control de fuente (por ejemplo, configuración, archivos compilados, etc.), agréguelos a la lista de ignorados . De esta manera, observa los archivos que olvida agregar porque siempre espera una lista vacía de archivos que se muestran como desconocidos para SVN.

2. Agregue un evento de confirmación posterior que enviaría un correo electrónico a la lista de correo de su desarrollador (o uno específico para este objetivo) relacionado con el cambio comprometido e idealmente el parche para él.

3. Integre con su rastreador de errores para que las referencias a confirmaciones aparezcan en las solicitudes de errores / funciones con enlaces a las diferencias. Los rastreadores de errores como MantisBT admiten esto.

4. Considere la posibilidad de realizar una integración con integración continua (por ejemplo, CruiseControl.NET ), NAnt for Build y NUnit / VS para pruebas unitarias. De esta manera, una vez que un usuario registra el código o en un intervalo programado, el código se compila, se ejecutan pruebas unitarias y el desarrollador recibe comentarios sobre el proceso. Esto también alertaría al resto del equipo si el repositorio está roto (es decir, no se construye).

Bueno, lo básico:

• Cree etiquetas antes de iniciar el control de calidad en una versión
• Cree etiquetas antes de cambios riesgosos (es decir, grandes refactores)
• Cree ramas para las versiones publicadas para congelar el código.
• Asegúrese de que la gente sepa actualizar antes de comenzar a trabajar en un fragmento de código y actualice una vez más antes de confirmarlo.
• SVN permite múltiples desprotecciones del mismo archivo por diferentes usuarios. Asegúrese de que todos resuelvan cualquier conflicto que pueda surgir.
• Nunca use la misma cuenta SVN para más de un usuario. Pueden resultar cosas terribles.

Las respuestas que da la gente son geniales. Mucho de esto se resume en el documento de usuario de svn para conocer las mejores prácticas para SVN .
Repetir:

1. Configure la estructura de su repositorio (debe tener la raíz del proyecto con el tronco, las ramas y las etiquetas debajo)
2. Elija su política de re-ramificación (sucursales privadas, sucursales por hito / lanzamiento / error, etc.) y apéguese a ella; recomendaría más sucursales en lugar de menos, pero no es necesario que haya sucursales privadas
3. Elija su política de reetiquetado: cuantas más etiquetas, mejor, pero lo más importante es decidir las convenciones de nomenclatura de sus etiquetas.
4. Elija su política para volver a comprometerse con el tronco: mantenga el tronco lo más "limpio" posible, debería poder liberarse en cualquier momento

Me gustaría resumir las mejores prácticas que sigo:

1. No comprometa binarios . Debe haber un repositorio separado para binarios, como Nexus , Ivy o Artifactory .

2. Debe haber una estructura de repositorio . Personalmente utilizo la siguiente estructura de repositorio:

   /trunk
   /tags
       /builds
           /PA
           /A
           /B
       /releases
           /AR
           /BR
           /RC
           /ST
   /branches
       /experimental
       /maintenance
           /versions
           /platforms
       /releases
   

3. Utilice una lista específica de tipos de ramas . Mi lista es la siguiente: experimental , mantenimiento , versiones , plataformas , lanzamientos .
4. Utilice tipos específicos de etiquetas : PA(pre-alfa), A(alfa), B(beta), AR(lanzamiento alfa), BR(lanzamiento beta), RC(candidato de lanzamiento), ST(estable).
5. Minimice la necesidad de fusionarse . Debería haber reglas sobre cuándo la fusión es posible / recomendada y cuándo no.
6. Numeración de versiones . Debe haber un enfoque de numeración de versiones establecido al que atenerse. Por lo general, se describe en un documento como Plan de gestión de la configuración de software, es parte de la documentación del proyecto de alto nivel. Personalmente, utilizo un enfoque complejo de numeración de versiones. Según este enfoque, las versiones tienen los siguientes patrones: Nxx (ramas de mantenimiento / soporte), NMx (rama de lanzamiento), NxK (compilación), NMK (lanzamiento).
7. Comprometerse con la mayor frecuencia posible . Si tiende a ser difícil (por ejemplo, cuando se deben realizar demasiados cambios para implementar la característica e incluso compilar código), se deben usar ramas experimentales.
8. Trunk debe contener el último desarrollo . Por ejemplo, cuando hay una elección de dónde desarrollar una nueva versión principal ( Nxx ) de la aplicación, en el tronco o en la rama, la decisión siempre debe tomarse a favor del tronco . La versión anterior debe ramificarse en la rama de mantenimiento / soporte . Asume que hay una clara distinción entre las versiones principales y sus detalles (arquitectura, compatibilidad) surgen lo antes posible .
9. Estricta política de "no romper la compilación" en las ramas de lanzamiento . Mientras tanto, no debería ser necesariamente estricto para el tronco , siempre que tenga un desarrollo experimental o una base de código que necesite resolver problemas de fusión.
10. Utilice svn: externals . Permitirá modularizar su proyecto, establecer un procedimiento transparente de gestión de versiones, dividir y conquistar diferentes funcionalidades.
11. Utilice el seguimiento de problemas . Podrá señalar la referencia del problema dentro del mensaje de confirmación.
12. Desactive los mensajes de confirmación vacíos . Se podría hacer usando ganchos de confirmación previa.
13. Defina qué ramas desea integrar continuamente . Por ejemplo, prefiero usar la integración continua para las ramas troncales , de mantenimiento y de liberación .
14. Establecer una política de integración continua para diferentes tipos de sucursales. Como señalé anteriormente, las reglas más estrictas de "no romper la construcción" se aplican a las ramas de liberación , mientras que las ramas troncales y de mantenimiento pueden romperse a veces. También hay una diferencia entre la lista de inspecciones ejecutadas en el tronco / mantenimiento y las ramas de liberación .

Puede encontrar un esquema de mis mejores prácticas de subversión en forma de diagrama que ilustra los principios fundamentales del enfoque de gestión de configuración de software que utilizo.

Una cosa que he encontrado muy útil es la propiedad svn: external , lo que significa que puede hacer referencia a directorios de otros repositorios al suyo. Ofrece formas realmente agradables de organizar su código y datos. Algunos ejemplos son:

1. Si tiene repositorios separados para codificar diferentes módulos / bibliotecas y referencia en los que está utilizando. Esto significa que puede tener un meta repositorio para cada ejecutable. Si se trata de un pequeño ejecutable que solo usa unos pocos módulos, no necesitará verificar todo el árbol. Un efecto de esto es que obtiene números de revisión SVN por módulo.
2. Agregar grandes datos binarios, como versiones compiladas de bibliotecas al repositorio de código, generalmente se considera un mal hábito, pero puede ser realmente conveniente. Si solo agrega todas las versiones de todas las bibliotecas que usa a un repositorio diferente, puede obtener lo mejor de dos mundos. Haces referencia en las versiones de las bibliotecas que usas en tu repositorio de código. Cuando revise su repositorio de código, obtendrá tanto el código como los binarios. Sin embargo, los binarios se almacenan en un gran repositorio del que no es necesario realizar una copia de seguridad tan rigurosamente como su código fuente y el repositorio de código fuente permanece pequeño y solo contiene texto.

Utilice la integración con su software de seguimiento de errores. Si usa Bugzilla , puede configurarlo para que si su comentario comience con "Error XXXX", su comentario SVN se agregue automáticamente como un comentario al error dado, incluido un enlace a su interfaz web SVN a esa revisión.

Conozca las herramientas y convenciones de ramificación y fusión de SVN.

La mejor manera de trabajar con otros miembros del equipo es dividir el trabajo en funciones / correcciones de desarrollo completas, luego trabajar en cambios individuales, cada uno en una rama. Luego, vuelva a fusionar los cambios con la rama / troncal de la línea principal cuando estén completados / listos / aprobados para fusionarse.

De esta manera, las personas pueden trabajar hacia un objetivo común (ya sea en la misma rama o en ramas separadas) sin chocar con otros cambios.

Su kilometraje puede variar, y esto puede ser excesivo para solo dos personas.

Lo hace mucho más fácil si usa buenas herramientas que se integran bien con SVN. Estos facilitan ver qué se ha cambiado y luego confirmar todos o parte de sus cambios y actualizar con frecuencia su copia de trabajo a la última versión en SVN.

Recomiendo Tortoise SVN (si usa Windows) y Visual SVN (si usa VS).

También vea si puede configurarlo para recibir un correo electrónico o una notificación similar cada vez que se confirma un cambio (generalmente también incluye el mensaje de confirmación y una lista de archivos modificados). Servicios como CVSDude ofrecen esto. Encuentro útil saber que se ha realizado una actualización y luego tener una idea de lo que contiene esa actualización antes de actualizar mi copia de trabajo.

Además de las políticas de ramificación et al. (donde un tamaño definitivamente no sirve para todos), debe tener buenas confirmaciones:

• El compromiso debe relacionarse con una sola pieza de trabajo si es posible; una corrección de errores, una nueva característica: debería haber algo de 'lógica' en los cambios que cometió
• La confirmación debe tener un comentario descriptivo que le ayudará a ubicarla navegando por el historial del repositorio. La mayoría de las personas sugieren escribir una sola oración al principio que describa todo el compromiso y una descripción más detallada a continuación.
• Si es posible, debe vincular la confirmación a su sistema de seguimiento de errores si es posible. Trac, Redmine y col. le permite crear enlaces de errores a confirmaciones y viceversa, lo que resulta muy útil.

La regla de oro para el control de código fuente: regístrese temprano, regístrese con frecuencia

Para obtener consejos sobre cómo organizar su repositorio:

• ¿Cómo organiza su repositorio de control de versiones?
• Libro SVN Capítulo 5. Administración del repositorio
• Disposición del repositorio

Consulte con su equipo acerca de sus cambios, o al menos observe la diferencia con mucho cuidado, antes de solucionar cualquier conflicto de fusión. Pídales que revisen el código combinado ellos mismos para asegurarse de que sus adiciones no se pierdan en la combinación.

Una cosa que he visto que reduce las confirmaciones rotas es tener buenos scripts de confirmación previa. Por ejemplo, puede ejecutar cualquier prueba unitaria antes de que se confirme el cambio. Esto hará que los compromisos sean un poco lentos, pero ahorrarás tiempo al evitar pisar los dedos de los pies de alguien y tener que disculparte. Por supuesto, esto se vuelve mucho más difícil de administrar cuando tienes un gran equipo de desarrollo y compromisos muy frecuentes.

Uno de los ejemplos de integración con el seguimiento de errores y la aplicación de la política de confirmación podrían ser los scripts de enlace pre / post-compromiso svn de Trac , que pueden rechazar la confirmación si el mensaje de confirmación no hace referencia a ningún ticket en el seguimiento de errores y agrega comentarios a los existentes. tickets basados ​​en el contenido del mensaje (es decir, el mensaje de confirmación puede contener algo como "Arreglos # 1, # 2 y # 8", donde # 1, # 2, # 8 son los números de tickets).

Mejores prácticas para usar SVN :

1. Cuando llegó por primera vez a la oficina y abrió su proyecto Eclipse , el primer paso que debe realizar es actualizar su proyecto.

2. Después de actualizar, comience su trabajo. Cuando termine su codificación, verifíquela correctamente, si su aplicación se ejecuta correctamente sin ninguna excepción. Una vez que esté seguro de que su código funciona bien, es hora de confirmar el código.

Nota: Mientras confirma el código, no se comprometa directamente. Realice una sincronización con el servidor y verifique cuáles son todas las necesidades que deben confirmarse. Nota: No confirme la carpeta completa una vez. Porque es posible que haya realizado algunos cambios en el archivo según sus necesidades o que haya eliminado algunos archivos en su sistema local. Pero la configuración es diferente en el servidor. Así que verifique los archivos individualmente y confirme el código.

3. No comprometa / actualice archivos de conflicto directamente.

4. ¿Cuándo anular y actualizar?

   Cuando esté bastante seguro de que no necesita ninguno de sus cambios locales y desea actualizar la copia del servidor por completo. Tenga en cuenta que una vez que realice la anulación y la actualización, no obtendrá ninguno de los cambios locales.

   Nota: No guarde el proyecto sin actualizarlo durante más de un día. Además, no guarde el código sin comprometerse durante muchos días.

5. Comunique quiénes están trabajando en el mismo componente y analice los cambios que han realizado todos los días.

6. No confirme las propiedades y el archivo de configuración a menos que haya alguna razón. Porque la configuración será diferente en un servidor y en la nube.

7. No comprometa las carpetas de destino en SVN, solo el código fuente y las carpetas de recursos deben mantenerse en un repositorio de SVN.

8. Cuando pierda su código, ¡no se asuste! Puede recuperar la copia anterior del historial de SVN.

9. No guarde el proyecto en varios lugares de su disco. Compruébelo en un solo lugar y trabaje con él.

SVN en sí mismo es un buen comienzo y algunos de los otros carteles han ofrecido excelentes sugerencias sobre las mejores prácticas.

Lo único que agregaría es que debería conectar SVN con CruiseControl o TeamCity para impulsar un proceso de integración continua. Esto enviará correos electrónicos de compilación y permitirá que todos sepan cuándo alguien rompió la compilación.

Será muy revelador desde el principio quién está siguiendo su proceso y quién no. Puede generar cierta fricción, pero su equipo estará mejor a largo plazo.

• Comentario preciso para cada compromiso

• ¡No rompa la construcción (principal)!

• Comprometerse tan pronto como cambie una unidad lógica

• Evite usar Subversion como herramienta de respaldo

• Un poco de ramificación / fusión como sea posible

.

Se pueden encontrar más detalles en las mejores prácticas de SVN .

¿Trabajar DEV en sucursales?

1. Compromisos frecuentes con su rama
2. Compromisos discretos / modulares para su rama ( consulte aquí )
3. Actualizar / fusionar desde el tronco con frecuencia. No te sientes en tu rama sin volver a basar

Tronco comunitario

1. Siempre debe construir / trabajar
2. Un problema por confirmación ( vea nuevamente aquí ) Principalmente para que usted u otros puedan retroceder las cosas una a la vez
3. No combine los cambios de refactorización / espacios en blanco con cambios lógicos. Tus compañeros de equipo tendrán dificultades para extraer lo que realmente hiciste de un compromiso

Recuerde que cuanto más incrementales, modulares, discretos y concisos haga sus confirmaciones, más fácil será para usted (o probablemente para otros):

• Retroceder gradualmente los cambios
• Date cuenta visualmente de lo que hiciste sin tener que examinar toneladas de espacios en blanco y cambios de nombre de variable.
• Los mensajes de confirmación significan más cuando la relación entre el trabajo realizado y la longitud del mensaje es menor.

Use esto para la plantilla de comentarios:

[tarea / historia xxx] [menor / mayor] [comentario] [comentario de seguimiento] [URL del error]