version control - usados - Control de fuente: ¿bloqueo frente a fusión?

svn version control (12)

Bloquear archivos puede no escalar muy bien para un equipo más grande. Con los sistemas de control de versiones que utilizan una gran cantidad de ramificaciones y fusiones, simplemente puede no ser práctico permitir que una sola persona otorgue tal control sobre el repositorio (por lo tanto, no escalar a un equipo más grande).

Con Subversion, por ejemplo, la bifurcación es una copia de puntero, por lo que puede crear fácilmente una rama TRY para evitar la corrupción del tronco si está experimentando con algo, pero desea comprometerse.

Con los sistemas de control de versiones distribuidas como Git, cada extracción es esencialmente una rama.

Muchos programadores que utilizan Visual Studio tienen dificultades para adaptarse al hecho de que en otros sistemas de control de origen, los archivos no necesitan ser bloqueados o revisados a un desarrollador en un momento dado.

Los defensores de la fusión dicen que permitir que dos personas trabajen en el mismo archivo acelera la productividad, ya que elimina la posibilidad de hacer cola para el mismo archivo fuente. También evita los casos en los que se debe escribir el código, pero la fuente se presta a un tipo que acaba de irse de vacaciones de dos semanas.

Los defensores de bloqueo dicen que se introducen muchos riesgos cuando más de una persona trabaja en el mismo archivo simultáneamente. La comunicación y coordinación entre los miembros del equipo se vuelve mucho más necesaria cuando se utiliza el modelo de fusión, según ellos. Además, muchas personas parecen desconfiar de las fusiones automatizadas.

¿Cuál es la razón más convincente para que uses un método sobre el otro?

Creo que el modelo de fusión es muy superior, es más flexible, los usuarios pueden trabajar en paralelo, sin esperar el uno al otro, y la cantidad de tiempo que lleva resolver los conflictos es mucho menor que el tiempo perdido por un modelo de bloqueo. La mayoría de las veces, los cambios realizados en un archivo no entran en conflicto y pueden combinarse automáticamente.

Probablemente sea por eso que es el modelo predeterminado en la mayoría de los sistemas de control de fuente modernos.

Pero al final, el factor crítico es siempre la comunicación del usuario . Cuando los usuarios se comunican mal, los conflictos seguramente aumentarán.

Habiendo cambiado de modelo bloqueado a modelo de fusión, haré las siguientes observaciones:

La mayoría de los usuarios fusionados tienden a permanecer bastante cerca de la versión "principal" de la rama en la que están desarrollando. Esto normalmente significa que los dramáticos problemas de fusión no son muy comunes.
En 10 años o más de uso del modelo de combinación, solo he experimentado un par de problemas de fusión realmente malos. En ambos casos, esto se debió a que 2 personas habían resuelto el mismo problema.
Normalmente resolvemos problemas de fusión sin comunicarnos con la otra parte;)
El modelo "bloqueo" VC está bien si un sistema se encuentra en una fase de mantenimiento estable con pocos cambios.
Bloquear modelo VC está bien si tu equipo es pequeño (yo diría que 1 o 2 personas;)

El modelo de fusión IMHO es muy superior porque me permite libertad mientras trabajo con código. Puede que no sea el mejor modelo para "oscurecer" con el código durante 1 semana, pero de nuevo con el modelo de "bloqueo" este es un problema igualmente grande. Nadie se oscurece con el código durante una semana.

La queja común contra el bloqueo de VCS es que usted tiene un problema cuando alguien va de vacaciones o de una conferencia y deja algunos archivos bloqueados :)

Las fusiones son buenas. Los programadores que trabajan en el mismo archivo deben comunicarse de todos modos. Si NO se están comunicando, hay problemas graves en ese código.

Merge es la forma natural de hacer las cosas, aporta disciplina, ahorra tiempo (imagine que los programadores terminan refabricando el mismo código).

El bloqueo es reactivo ... la fusión es proactiva ...

Merge es el enfoque correcto, pero para agregar a la respuesta anterior, debe respetar unos pocos criterios para ser eficiente.

la sucursal está bien definida (no representa un esfuerzo de desarrollo "demasiado amplio", en el que los desarrolladores tendrían que modificar todos los archivos, multiplicando las posibilidades de modificación simultánea múltiple de un archivo común con posible conflicto)
la notificación (que el archivo ya está siendo modificado) se hace claramente cuando un desarrollador comienza a modificar un archivo ya reservado por otro colega.
los archivos de configuración comunes (donde cada desarrollador debe seguir un conjunto de valores predefinidos, a excepción de una ruta local personalizada que debe redefinirse para cada programador) no son "reservados" por nadie, sino simplemente modificados en su espacio de trabajo privado.

Además, tenga en cuenta que también existe la posibilidad de tener una combinación de ambos:

"bloqueo": el primer desarrollador que modifique un archivo será el primero en comprometerlo. Todos los demás desarrolladores también pueden modificar el mismo archivo, pero tendrán que esperar al primero para confirmar antes de comenzar a fusionar sus propias modificaciones.
"fusionar": cuando un desarrollador compromete un archivo ya modificado por un colega, fusiona sus cambios.

En ese caso, debe asegurarse de que exista un mecanismo de "liberación" para evitar ser bloqueado por el primer desarrollador.

Los defensores de bloqueo están equivocados, si hay alguien que abogue por eso. Todos los equipos que conocí utilizando el anticuado sistema de estilo de bloqueo se han quejado al respecto y han mirado con anhelo a las personas que usan otros métodos. Trabajé en un proyecto para un lugar que fue forzado a usar un sistema de bloqueo y opté por usar NO CONTROL en absoluto (así que configuré una rama SVN secreta , aunque prefiero Bzr o Git).

Entonces, sospecho que los únicos " defensores de bloqueo " son empleados del departamento de marketing de un sistema de bloqueo.

El modelo de fusión es como nadar. Las personas que no lo han hecho al principio tienen miedo, pero a todos los que saben cómo hacerlo les encanta. Algunas personas tienen malas experiencias desde el principio, y la mayoría de la gente simplemente tiene que experimentarlo y superar ese miedo inicial.

Los mayores problemas de fusión que tuve fueron en un sitio donde teníamos control de versiones con bloqueo (SCCS, para ser precisos, esto fue hace un tiempo).

Lo que sucedería es que esa persona A estaría trabajando en algo, y se le sacaría el archivo. La persona B recibiría una solicitud urgente para arreglar algo para un cliente, y tendría que cambiar ese archivo.

Esto se jugó de varias maneras. Algunas veces, A registraba, B hacía un cambio, y A continuaba desde la copia de trabajo de A y borraba el cambio de B. A veces, B comenzaba con una copia copiada, ya que el tiempo era esencial y los cambios podían tardar un tiempo en volverse correctos, y sobrescribir los cambios de A. A veces, los cambios de B interactuarían con los cambios de A, y algunos de los cambios de A serían destruidos o perdidos. No hubo advertencia en este último caso.

En un VCS de fusión, A y B realizan sus cambios, y el sistema se asegura de que no se pierda nada. En el último caso, el VCS nota el conflicto, por lo que no se perderá.

También hubo un problema con hacer un cambio más grande en un archivo de programa, ya que podría ser interrumpido por las correcciones necesarias, lo que hace que sea mucho más difícil de terminar.

Nunca he visto un entorno de producción donde sea posible garantizar que dos personas no tengan que trabajar en el mismo archivo aproximadamente al mismo tiempo. La combinación de VCS maneja bien esa situación. Los VCS de bloqueo no.

Tenía mucho miedo de la idea de fusionarme, teniendo recuerdos de noches tratando de fusionar el código en los años 80. Sin embargo, descargué Subversion y Git y jugué con ellos un poco, y estoy impresionado con su promesa. Es una pena que soy el único aquí que es.

Una cosa que he hecho que puedes intentar: haz un seguimiento de ti mismo. Como el modelo de bloqueo es más pesimista, esto es fácil de hacer si trabaja bajo ese modelo. Cada vez que tenga un conflicto de bloqueo con otro desarrollador, vaya y hable con ellos. Mantenga un registro de lo siguiente:

Cuantas veces no significaron echarle un vistazo / se olvidó de él / no sabía que lo habían revisado.
Cuántas veces no están disponibles (de vacaciones, enfermos, etc.).
Cuántas veces legítimamente lo han revisado, pero están modificando partes del archivo totalmente no relacionadas con lo que desea modificar.
Cuántas veces modificaron una parte del archivo que entraría en conflicto con los cambios que deseaba realizar.

4 es la única situación en la que se puede argumentar que el bloqueo lo ayudó, y cubre todos los casos. Lo que he encontrado en los últimos 3 años que he estado haciendo esto es que casi todos los problemas son de la variedad 1-3. Creo que encontré 4 una vez. Pero si suma todo el tiempo perdido en 1-3, es tremendo.

La fusión siempre es problemática y contraproducente, y debe evitarse a toda costa. La fusión de grandes cambios de código y archivos refactorados es una molestia. Forzar un modelo de bloqueo optimista en todos los desarrolladores es incorrecto.

Creo que depende del caso. ¿Tomarías un avión si sabes que los archivos que controlan el avión fueron cambiados simultáneamente por muchas personas y luego se fusionaron?

En aplicaciones tontas, se puede usar el enfoque de fusión, pero si hablamos de sistemas serios ... como sistemas bancarios, etc.