Establezca un control de salida y locking frente a actualización y fusione control de versiones debate

He usado controles de fuente durante algunos años (si count los años de Source Safe), pero de ninguna manera soy un experto. Actualmente estamos usando una versión anterior de Sourcegear Vault. Nuestro equipo actualmente usa un model de verificación y locking. Preferiría cambiar a un model de actualización y fusión, pero necesito convencer a los otros desarrolladores.

La razón por la que los desarrolladores (no yo) configuraron para funcionar como check out y lock fue debido a files renegados. Nuestra empresa trabaja con una empresa de consultoría para hacer gran parte de nuestro trabajo de desarrollo. Hace algunos años, mucho antes de mi time aquí, tenían el control de fuente configurado para la actualización y la fusión. Los consultores fueron a registrarse, pero se encontraron con un error de fusión. Luego eligieron trabajar en modo desconectado durante meses . Cuando finalmente llegó la hora de probar el proyecto, aparecieron muchos errores y se descubrió que las bases de los códigos eran dramáticamente diferentes. Semanas de trabajo tuvieron que ser rehechas. Así que fueron a verificar y bloquear como la solución.

No me gusta el check out y el locking, porque hace que sea muy difícil para 2 o más personas trabajar en el mismo proyecto al mismo time. Cada vez que agrega un nuevo file de cualquier tipo o cambia el nombre de un file, el control de origen verifica el file .csproj. Eso evita que otros desarrolladores agreguen / renombren files.

Consideré hacer solo el file .csproj como mergable, pero el sitio de Sourcegear dice que esta es una mala idea, porque csproj es IDE autogenerado y que no puede garantizar que dos files diferentes generados por VS produzcan el mismo código.

Mi amigo (el otro desarrollador) me dice que la solución es verificar de inmediato su proyecto. Para mí, el problema con esto es que puedo tener una copy local que no se comstackrá y podría tomar time get una compilation. Podrían pasar horas antes de que la compilation funcione, lo que significa que durante ese time, nadie más podría crear y renombrar files.

Yo digo que la solución correcta es cambiar a un model que se puede combinar. Mi respuesta al problema de los "files renegados" es que se trató de una cuestión de disciplina de progtwigdor deficiente y de que no se debe utilizar una opción de progtwigdor más débil como solución para una disciplina deficiente; en su lugar, debe tomar medidas para corregir la falta de disciplina del progtwigdor.

Entonces, ¿quién tiene razón? ¿El check-in es una respuesta legítima al problema del file renegado? ¿O el problema de .csproj demasiado complicado para múltiples desarrolladores? ¿O está Sourcegear mal y que debería estar bien establecer el file csproj para actualizar y fusionar?

El problema con la actualización y fusión con el que tropezaron se debió a la falta de comunicación entre su grupo y el grupo de consultoría, y a la falta de comunicación del grupo de consultoría con su grupo sobre 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 tendría que 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 acepto que la actualización / combinación es mejor. Pero creo que el verdadero problema está en la comunicación a las personas de tu (s) grupo (s), y cómo eso se vuelve aparente en el uso del control de versiones, y si las personas en los grupos están a bordo / cómodas con el process de control de versiones. ve seleccionado. Tenga en count que cuando digo esto, mi propio grupo en el trabajo está luchando exactamente por lo mismo, solo con Agile / SCRUM en lugar de VC. Es doloroso, es molesto, es frustrante, pero el truco (creo) es identificar el problema de raíz y solucionarlo.

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

  1. Use un sistema de control de fuente adecuado (svn, mercurial, git, …)
  2. Si vas a hacer muchas ramificaciones, no uses nada less reciente que svn 1.6. Supongo que mercurial / git sería una solución aún mejor, pero aún no tengo mucha experiencia práctica para usarlos.
  3. Si las personas trabajan constantemente en las mismas partes del sistema, considere el layout del sistema. Indica que cada unidad tiene demasiada responsabilidad.
  4. Nunca, nunca acepte a personas fuera de línea por más de un día más o less. Las excepciones a esta regla deberían ser extremadamente raras.
  5. Hablar entre sí. Deja que los otros desarrolladores sepan en qué estás trabajando.

Personalmente, evitaría tener files de proyecto en mi repository. Pero, de nuevo, nunca bloquearía a los desarrolladores con una herramienta. En cambio, usaría un sistema de compilation que generara files de proyecto / makefiles / lo que sea (CMake es mi sabor por hacer esto).

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

He trabajado en proyectos exitosos con equipos de más de 40 desarrolladores usando el model de actualización y fusión. Lo que hace que este método funcione es la fusión frecuente: los trabajadores independientes están continuamente actualizando (fusionando) los cambios desde el repository, y todos con frecuencia combinan sus cambios (tan pronto como pasan las testings básicas).

Fusionarse con frecuencia tiende a significar que cada combinación es pequeña, lo que ayuda mucho. Las testings con frecuencia, tanto en las bases de datos individuales como en las salidas nocturnas desde el repository, son de gran ayuda.

Soy el gerente de desarrollo de una pequeña empresa, solo 3 progtwigdores. Los proyectos en los que trabajamos a veces toman semanas y empleamos el estilo de implementación big bang, shock y awe. Esto significa que tenemos muchos cambios en la database y cambios de progtwig que deben funcionar perfectamente la noche que implementamos. Pagamos un progtwig, lo cambiamos y lo dejamos a un lado porque implementarlo antes que todo lo demás hará que otras 20 cosas exploten. Estoy para el check out y el locking. De lo contrario, otra persona podría cambiar algunas cosas sin darse count de que el progtwig ya tuvo cambios masivos. Y la fusión solo ayuda si no ha realizado cambios en la database o cambios en otros sistemas que no están bajo control de fuente. (Microsoft CRM, básicamente cualquier software empaquetado que sea extensible a través de la configuration)

Estamos utilizando subversion sin restricciones de check-in / check-out en ningún file en un entorno altamente paralelo. Acepto que el problema de los files renegados es una cuestión de disciplina. No usar merge no resuelve el problema subyacente, ¿qué impide que el desarrollador copie su propia copy "fija" de código sobre las actualizaciones de otras personas?

Merge es una pita, pero se puede minimizar al registrar y actualizar su copy local temprano y con frecuencia. Estoy de acuerdo con usted con respecto a la ruptura de checkins, deben evitarse. Por otra parte, la actualización de su copy local con los cambios registrados le obligará a fusionar los cambios correctamente para que cuando finalmente registre las cosas se desarrollen sin problemas.

Con respecto a los files .csproj. Son solo text, de hecho se pueden fusionar si dedica time a averiguar cómo está estructurado el file, hay references internas que deben mantenerse.

No creo que ningún file que se requiera para build un proyecto deba excluirse del control de la versión. ¿Cómo puede rebuild o rastrear de manera confiable los cambios si partes del proyecto no se graban?

IMO, los files de proyecto como .csproj no deberían formar parte del sistema de control de versiones, ya que realmente no son fuente.

También es casi seguro que no se puedan fusionar.

    Intereting Posts