Cómo alentar más compromisos frecuentes para SVN

Question

Un grupo de desarrolladores con el que estoy trabajando cambió de VSS a SVN hace aproximadamente medio año. La transición de CheckOut-CheckIn a Update-Commit ha sido difícil para una cantidad de usuarios. Ahora que ya no están obligados a verificar sus archivos cuando terminan (o con mayor precisión, ahora que nadie más puede ver que tienen el archivo desprotegido y les piden que lo vuelvan a verificar para liberar el bloqueo en el archivo), ha sucedido en más de una ocasión que los usuarios han olvidado confirmar sus cambios hasta mucho después de que se hayan completado.

Aunque la mayoría de los usuarios son buenos acerca de Commitir sus cambios, el problema es tan grave que la decisión podría tomarse para forzar a los usuarios a get locks on all files in SVN before editing. Prefiero no ver que esto suceda, pero no sé cómo mejorar la situación de otra manera. Entonces, ¿puede alguien sugerir maneras de hacer cualquiera de las siguientes:

1. Track lo que los usuarios los archivos se han editado pero no han tenido cambios todavía comprometidos para
2. Fomentar usuarios a ser más consistente con confirmar los cambios cuando se hacen
3. ayudar a terminar fuera de la educación de los usuarios necesarios para que la gente se utilizan para el nuevo paradigma de control de versiones

fuera de la caja soluciones bienvenidos (es decir: programa de escritorio que recuerda a los usuarios para cometer si no han don Por lo tanto, en un intervalo determinado, obtendrá automáticamente las estadísticas de las tasas de aceptación del usuario y enviará correos electrónicos de advertencia si la frecuencia cae por debajo de un cierto umbral, etc.

Answer 1

... los usuarios han olvidado confirmar sus cambios hasta mucho después de que se hayan completado.

Creo que este es el problema aquí. ¿Cómo se puede "completar" una característica/corrección de errores si no está registrada? ¿Tiene un sistema de seguimiento de problemas que registra problemas pendientes? ¿Tiene un sistema de integración continua que ejecuta pruebas unitarias tan pronto como se realiza un checkin?

Si los desarrolladores simplemente están haciendo lo suyo sin responsabilidad, entonces no es sorprendente que tenga problemas para lograr que todos cooperen. Necesitará algún tipo de supervisión (¿gerente de proyecto ?, ¿jefe de equipo?) Que es responsable de asegurarse de que los desarrolladores individuales cooperen con el resto del equipo de desarrolladores.

Answer 2

Lea el registro de compromiso y pregunte a las personas sobre su estado y cuándo habrán verificado sus cambios. Comprometerse con piezas enteras es mejor que comprometerse como si fuera una forma de 'salvar'.

¿Cómo puede un desarrollador terminar algo y olvidarse de registrarlo? ¿El proceso de entrega es tal que el usuario ejecuta una compilación desde la propia máquina del desarrollador?

Answer 3

¿Utiliza algún tipo de software de seguimiento de funciones/errores?
Puede pedirles que incluyan un número de revisión cuando marquen el trabajo completado.

Answer 4

Creo que el problema que tiene es en realidad la falta de un combinador de sistema de construcción con un seguimiento de errores/características/cambios. Con un sistema de seguimiento de fallas y una construcción contigua, el desarrollador puede reclamar 'completo' solo después de que sus cambios llegaron a la compilación automatizada y se genera una versión que contiene los cambios, pasa las pruebas de validación de compilación y se descarta en la ubicación de lanzamiento de lanzamiento. Como la única forma de hacer un cambio para 'convertirlo' en una construcción es registrarse (una posible integración inversa de la rama característica en la rama principal/troncal), los desarrolladores tendrán que registrarse, de lo contrario, nunca terminarán nada. .

Answer 5

En un grupo de desarrollo de la pequeña, he visto un email diario enviado al grupo de carreras de caballos 'que muestra el número de confirmaciones, el total de líneas, etc' lista que muestra un resumen de las confirmaciones desde el día anterior y un oficial de correo' dentro de los últimos 30 días para ser útil. Obviamente, no puedes usar la cantidad de checkins como cualquier tipo de métrica de rendimiento, pero sigue siendo divertido y mantiene el control de la fuente en la mente de todos. "Oye, Joe acaba de pasarme por los controles este mes, oh, espera, nunca revisé ese código ayer".

Esto también tiene otras ventajas ya que las personas entran por la mañana y lo leen en su café o lo que sea que guarde lo que otras personas están haciendo en la mente de los desarrolladores. Cuando entramos en el 'congelamiento del código' y nos acercamos a un lanzamiento, en realidad cambiamos el correo electrónico de solo un resumen de checkin, para incluir los 'diffs' reales, de modo que cada línea de código tenga muchos ojos de inmediato.

Answer 6

Normalmente, lo que anima a los desarrolladores a cometer con frecuencia es la autopreservación. Cuando las actualizaciones se vuelven difíciles para ellos debido a conflictos de fusión y descubren que el problema se alivia presionando sus cambios, se comprometerán más a menudo.

Parece que hay algo fundamentalmente malo, sin embargo. ¿Cómo están obteniendo sus desarrolladores los cambios en el producto lanzado sin pasar por el VCS? Deberías cerrar esa puerta trasera.

Answer 7

Si usó VSS anteriormente, probablemente trabaje en Visual Studio. AnkhSVN tiene una ventana de cambios pendientes, como la de TFS y VSS. Esta ventana de herramientas muestra automáticamente qué archivos se modifican localmente en su solución.

El uso de esta ventana de cambio pendiente para sus cambios facilita el trabajo en cambios pequeños/lógicos y confirma esos cambios anticipadamente en lugar de posteriores.

[Ver captura de pantalla de una versión anterior AnkhSVN]

Answer 8

obtener una máquina de construcción automatizado (o al menos una persona muy dedicada haciendo construye), y desplegar solamente de esa máquina. Entonces, su código no se implementa hasta que se compromete, y ayuda a garantizar que nada quede fuera del repositorio.

Además, tener al menos unos pocos miembros de un equipo comprometiéndose temprano y, a menudo, por lo general anima a otros a mantenerse al día también, porque el compromiso lento tiene que lidiar con más conflictos de fusión locales.

Answer 9

Un rastreador de errores/características decente te permitirá agregar un número de error cuando confirmes tus cambios. Por ejemplo, si estoy ejecutando Redmine, puedo comprometerme con "Fixes # 323" en algún lugar de mi mensaje de confirmación de subversión y cerrará automáticamente el error/tarea 323. Su configuración es muy sencilla; solo tienes que decirle a Redmine dónde está el repositorio, lo que se pide de todos modos.

De esta forma puede ver qué cambios se han cometido contra cada error, y los errores sin confirmación estarán abiertos (a menos que se cierren manualmente). Puede asignar errores a los hitos, y antes del lanzamiento de un hito, revise los commits contra el error.

Trac también lo hace, al igual que muchos otros.

Answer 10

automatizar sus construcciones y despliegues, y hacerlo parte del proceso que nada se "hace" hasta que se prueba en el servidor de prueba