version control - tipos - ¿Por qué evitar el bloqueo pesimista en un sistema de control de versiones?
software para control de versiones de documentos (10)
si sus archivos de códigos son tan grandes que constantemente tiene más de una persona trabajando en ellos al mismo tiempo
Si este es el caso, es hora de que los "seres humanos" se hagan cargo y coordinen cualquier cambio. En el caso ideal, y si la gestión de su proyecto es buena, rara vez llegará a un momento en el que intente cambiar un archivo bloqueado porque alguien habrá coordinado las cosas para que esto prácticamente no suceda.
En otras palabras, sabrá que "Bob" está haciendo un gran conjunto de cambios en los componentes X / Y / Z; si tiene una corrección de errores en el componente X, sabrá que debe hablar con Bob antes de intentar enviar los cambios.
Como digo, esto es ideal;)
Basándome en algunas publicaciones que he leído sobre el control de versiones, parece que la gente piensa que el bloqueo pesimista en un sistema de control de versiones es algo malo. ¿Por qué? Entiendo que impide que un desarrollador envíe un cambio mientras que otro tiene el archivo desprotegido, pero ¿y qué? Si sus archivos de códigos son tan grandes que constantemente tiene más de una persona trabajando en ellos al mismo tiempo, le presento que debe reorganizar su código. Divídalo en unidades funcionales más pequeñas.
La integración de cambios de código concurrentes es un proceso tedioso y propenso a errores incluso con las herramientas que proporciona un buen sistema de control de versiones para facilitarlo. Creo que debería evitarse si es posible. Entonces, ¿por qué el bloqueo pesimista se desalienta?
El bloqueo pesimista es una buena idea si es probable que haya conflictos serios. Para la mayoría de los programas, no verá ningún conflicto grave, por lo que el bloqueo pesimista es bastante inútil. Las excepciones a esto serían si usted es:
- Trabajando en archivos binarios donde no se puede fusionar realmente: los recursos artísticos (modelos, texturas, etc.) son un buen ejemplo.
- Trabajar con usuarios no técnicos que no saben cómo fusionarse, y no quieren aprender (principalmente artistas, pero algunos escritores técnicos también se pondrán en forma).
- Trabajar en archivos muy grandes que no se pueden fusionar o dividir fácilmente en archivos más pequeños debido al alto grado de complejidad (nunca antes se había visto una situación así, pero estoy seguro de que es posible).
De otra manera...
Con respecto al caso de Bob y John, los sistemas cooperativos como svn no evitan este escenario más de lo que lo hace un sistema de bloqueo. Puedo ''actualizar'' FooBar.java, que satisface svn que tengo la última edición, luego eliminar ese archivo localmente y sobrescribirlo con mi propia copia personal que hice sin tener en cuenta la versión de referencia, y comprobar eso, felizmente destruyendo los cambios del otro tipo. Ningún sistema, bloqueo o no, impide esto, por lo que no veo el punto de siquiera llevarlo al debate.
El verdadero problema es decidir cuál es tu equilibrio entre
probabilidad de errores de fusión vs. inconveniencia causada por personas que bloquean archivos
La noción de que un sistema de bloqueo o no bloqueo es "superior" no tiene sentido.
He usado VSS, en su modo de bloqueo completo predeterminado, con 6 desarrolladores, y funcionó como un sueño. Ocasionalmente, alguien olvidaba liberar un candado y teníamos que buscarlos o romper el candado manualmente y fusionarlos a mano cuando regresaban, pero esto era muy mínimo. He visto svn arruinar su combinación automática más de una vez, de modo que realmente no confío en eso. No siempre marca un ''conflicto'' cuando dos personas han cambiado el mismo archivo de una manera que no se puede fusionar automáticamente.
Por el contrario, he visto a la gente impacientarse con las cerraduras de VSS, editar sus propias copias y revisarlas descuidadamente sobre el código de otras personas, y he visto a svn atraparme fácilmente cuando podría intentar accidentalmente verificar algo eso ha sido cambiado por otra persona desde que lo revisé por última vez.
Mi punto es que este no es un debate sensato. El éxito de cualquiera de los sistemas se reduce a cómo gestiona los puntos de conflicto cuando ocurren, no si un sistema u otro es mejor.
Depende de tu proyecto y tu equipo en general. El bloqueo pesimista es bueno porque es fácil de entender: ¡un desarrollador a la vez, y no es necesario fusionarse!
Sin embargo, lo malo de esto es exactamente eso: un desarrollador a la vez. Tengo la situación ahora donde un colega se ha ido al sitio y, antes de irse, revisó todo para que, si tuviera que corregir algún error, pudiera regresar y verificara todos sus cambios en ... bueno para él , pésimo para mí y el resto del equipo de desarrollo en la base.
Si puede evitar el bloqueo pesimista en su equipo, está bien usarlo, realmente, la razón principal por la que la gente lo odia es porque es la práctica predeterminada de Visual SourceSafe. Si no está seguro de fusionar muchos cambios, entonces tiene otra razón para usarlo: si alguna vez ha utilizado un SCM con bloqueo optimista y ha combinado una fusión, sabrá lo difícil que es recuperarlo.
Si puede manejar la fusión, entonces el bloqueo optimista es superior y lo recomendaría, pero no tiene que entregar su tarjeta geek si no desea usarla.
El bloqueo pesimista es (experiencia personal) en el camino de la colaboración. A veces es reemplazado fácilmente por una buena comunicación de equipo. Simplemente diciendo "Oye, voy a trabajar en estos pocos archivos por un tiempo".
He trabajado en equipos de 2 a 6 personas sin bloqueo y nunca tuvimos un problema, más allá de algunas fusiones habituales y necesarias.
También trabajé una vez con bloquear un proyecto alojado de Visual SourceSafe . Fue en mi humilde opinión contraproducente.
- Bob necesita editar FooBar.java
- John lo ha revisado para editarlo
- Bob edita su copia local de todos modos y la guarda como FooBar.java.bak
- Cuando John lo revisa, Bob lo revisa
- Bob copia FooBar.java.bak sobre él y lo comprueba
- John consigue volver a implementar su función
Lo he visto suceder una y otra vez. Los desarrolladores hacen esto porque este proceso es molesto:
- Bob necesita editar FooBar.java
- John lo ha revisado para editarlo
- Bob tiene que esperar moviendo sus pulgares hasta que John termine
El bloqueo pesimista se siente como una hora amateur, lo siento.
- Ve a jugar con Source Safe y deja que un desarrollador se vaya para dos semanas de vacaciones. Agregue a eso que los administradores de VSS no están cerca. Ahora tiene una solución para publicar pero no puede debido al desarrollador
- Si tiene varias funciones y / o correcciones de errores en proceso. No importa cuán pequeño se rompa su código, aún tendrá contención por un archivo central.
Los desarrolladores de software siempre son optimistas, ¡solo mire sus habilidades de estimación!
En la práctica, encontramos que los conflictos son raros y que los beneficios de no tener que preocuparse por bloquear superan el paso ocasional de resolución de conflictos.
Si un desarrollador no puede manejar la fusión y la solución de conflictos, debe ser reeducado.
Es común que incluso los archivos pequeños obtengan conflictos, por ejemplo, con JSP, una persona (desarrollador web) podría estar cambiando el código de diseño, y otra persona podría cambiar la API para el modelo que utiliza el JSP.
- No siempre tienes la opción de separar los archivos
- Archivos de configuración
- Archivos XML
- Incluso los archivos relativamente pequeños pueden contener partes distintas a las que más de un desarrollador necesita acceder
- Bibliotecas
- Utilidades
- Las herramientas de fusión son mucho más inteligentes que nunca.
- Los conflictos son bastante raros
- Reduce las demoras debido a que los desarrolladores tienen archivos "accidentalmente" prestados