Establezca una comprobación y bloquee vs actualización y combine el debate sobre el control de versiones

Question

He usado controles de fuente durante algunos años (si cuenta los años de Fuente segura), pero de ninguna manera soy un experto. Actualmente estamos utilizando una versión anterior de Sourcegear Vault. Nuestro equipo actualmente utiliza un modelo de verificación y bloqueo. Prefiero cambiar a un modelo de actualización y fusión, pero necesito convencer a los otros desarrolladores.

La razón por la que los desarrolladores (no yo) configuramos para trabajar como desproteger y bloquear fue debido a los archivos renegados. Nuestra empresa trabaja con una empresa de consultoría para realizar gran parte de nuestro trabajo de desarrollo. Hace algunos años, mucho antes de mi tiempo aquí, tenían el control de origen configurado para actualizar y fusionar. Los consultores fueron a registrarse, pero encontraron un error de fusión. Luego eligieron trabajar en modo desconectado durante meses . Cuando finalmente llegó el momento de probar el proyecto, aparecieron muchos errores y se descubrió que las bases del código eran dramáticamente diferentes. Semanas de trabajo terminaron teniendo que rehacerse. Entonces fueron a revisar y bloquear como la solución.

No me gusta retirar y bloquear, porque hace que sea muy difícil para 2 o más personas trabajar en el mismo proyecto al mismo tiempo. Cada vez que agrega un nuevo archivo de cualquier tipo o cambia el nombre de un archivo, el control de origen comprueba el archivo .csproj. Eso evita que otros desarrolladores agreguen / renombren archivos.

Pensé en hacer solo el archivo .csproj como fusionable, pero el sitio de Sourcegear dice que es una mala idea, porque csproj es IDE generado automáticamente y que no puede garantizar que dos VS diferentes generados los archivos producirán el mismo código.

Mi amigo (el otro desarrollador) me dice que la solución es verificar inmediatamente su proyecto. Para mí, el problema con esto es que puedo tener una copia local que no se compilará y podría tomar tiempo obtener una compilación. Pueden pasar horas antes de que la compilación funcione, lo que significa que durante ese tiempo, nadie más podrá crear y renombrar archivos.

Respondo que la solución correcta es cambiar a un modelo fusionable. Mi respuesta a los "archivos renegados" El problema es que se trataba de una mala disciplina del programador y que no se debe utilizar una opción de programador más débil como una solución para la mala disciplina; en su lugar, debe tomar medidas para corregir la falta de disciplina del programador.

Entonces, ¿quién tiene razón? ¿El proceso de registro es una respuesta legítima al problema del archivo renegado? ¿O el problema de .csproj es demasiado complicado para múltiples desarrolladores? ¿O está equivocado Sourcegear y debería estar bien configurar el archivo csproj para actualizar y fusionar?

Answer 1

El problema con la actualización y la fusión con el que se encontraron se originó en una falta de comunicación entre su grupo y el grupo consultor, y una falta de comunicación del grupo consultor a su grupo en cuanto a cuál era el problema, y ??no necesariamente un problema con el método de control de versiones en sí. Idealmente, el problema de comunicación debería resolverse primero.

Creo que su análisis técnico de las diferencias entre las dos metodologías de control de versiones es sólido, y estoy de acuerdo en que actualizar / fusionar es mejor. Pero creo que el verdadero problema está en la comunicación con las personas en su (s) grupo (s), y cómo eso se hace evidente en el uso del control de versiones, y si las personas en los grupos están a bordo / cómodas con el proceso de control de versiones ' he seleccionado. Tenga en cuenta que mientras digo esto, mi propio grupo en el trabajo está luchando exactamente por lo mismo, solo con Agile / SCRUM en lugar de VC. Es doloroso, molesto, es frustrante, pero el truco (creo) es identificar el problema raíz y solucionarlo.

Creo que la solución aquí es asegurarse de que (cualquiera que sea el método de VC elegido) se comunique bien a todos, y esa es la parte complicada: no solo debe involucrar a su equipo con una técnica de VC particular, sino también El equipo de consultoría. Si alguien en el equipo de consultoría no está seguro de cómo realizar una operación de fusión, bueno, intente entrenarlos. La clave es mantener la comunicación abierta y clara para que los problemas puedan resolverse cuando aparezcan.

Answer 2

1. Utilice un sistema de control de fuente adecuado (svn, mercurial, git, ...)
2. Si va a hacer muchas ramificaciones, no use nada menos reciente que svn 1.6. Supongo que mercurial / git sería una solución aún mejor, pero todavía no tengo demasiada experiencia práctica al usarlos.
3. Si las personas trabajan constantemente en las mismas partes del sistema, considere el diseño del sistema. Indica que cada unidad tiene demasiada responsabilidad.
4. Nunca, nunca aceptes personas sin conexión durante más de un día más o menos. Las excepciones a esta regla deberían ser extremadamente raras.
5. Hablen entre ellos. Deje que los otros desarrolladores sepan en qué está trabajando.

Personalmente, evitaría tener archivos de proyecto en mi repositorio. Pero, de nuevo, nunca bloquearía a los desarrolladores con una herramienta. En su lugar, usaría un sistema de compilación que generara archivos de proyecto / makefiles / lo que sea (CMake es mi gusto por hacer esto).

EDITAR: Creo que bloquear archivos está arreglando los síntomas, no la enfermedad. Terminarás teniendo desarrolladores que no harán nada si esto se convierte en un hábito.

Answer 3

He trabajado en proyectos exitosos con equipos de más de 40 desarrolladores que utilizan el modelo de actualización y combinación. Lo que hace que este método funcione son las fusiones frecuentes: los trabajadores independientes actualizan (fusionan) continuamente los cambios desde el repositorio, y todos frecuentemente combinan sus cambios (tan pronto como pasan las pruebas básicas).

La fusión con frecuencia tiende a significar que cada combinación es pequeña, lo que ayuda mucho. Las pruebas frecuentes, tanto en bases de código individuales como en los pagos nocturnos desde el repositorio, son de gran ayuda.

Answer 4

Estamos usando subversion sin restricciones de entrada / salida en ningún archivo en un entorno altamente paralelo. Estoy de acuerdo en que el problema de los archivos renegados es una cuestión de disciplina. No usar la combinación no resuelve el problema subyacente, lo que impide que el desarrollador copie su propio '' fijo '' copia del código sobre las actualizaciones de otras personas?

La fusión es una pita, pero eso puede minimizarse al registrarse y actualizar su copia local de manera temprana y frecuente. Estoy de acuerdo con usted con respecto a romper los registros, deben evitarse. La actualización de su copia local con los cambios registrados, por otro lado, lo obligará a combinar sus cambios correctamente para que cuando finalmente se registre, las cosas salgan bien.

Con respecto a los archivos .csproj. Son solo texto, de hecho son fusionables si pasa el tiempo para descubrir cómo está estructurado el archivo, hay referencias internas que deben mantenerse.

No creo que ningún archivo que se requiera para construir un proyecto deba excluirse del control de versiones. ¿Cómo puede reconstruir o rastrear cambios de manera confiable si no se registran partes del proyecto?

Answer 5

Soy el gerente de desarrollo de una pequeña empresa, solo 3 programadores. Los proyectos en los que trabajamos a veces toman semanas y empleamos el estilo de implementación de Big Bang, Shock and Awe. Esto significa que tenemos muchos cambios en la base de datos y cambios en el programa que tienen que funcionar perfectamente en la noche que implementamos. Revisamos un programa, lo cambiamos y lo reservamos porque implementarlo antes de todo lo demás hará que otras 20 cosas exploten. Estoy para salir y bloquear. De lo contrario, otra persona podría cambiar algunas cosas sin darse cuenta de que el programa ya ha tenido cambios masivos. Y la fusión solo ayuda si no ha realizado cambios en la base de datos o cambios en otros sistemas que no están bajo control de origen. (Microsoft CRM, básicamente cualquier software empaquetado que es extensible a través de la configuración)

Answer 6

En mi opinión, los archivos de proyecto como .csproj no deberían formar parte del sistema de versiones, ya que en realidad no son fuente.

Es casi seguro que tampoco son fusionables.