version control - vcs - Bloqueo de control de revisión: ¿el jurado todavía está fuera?
que es vcs (12)
El bloqueo exclusivo es lo mejor que puede hacer en el peor de los casos, por lo que su presencia siempre me dice que hay problemas mayores.
Uno de esos problemas más grandes es la mala organización del código. En uno de mis conciertos de consultoría para una gran empresa de telecomunicaciones, ocho de cada treinta miembros del equipo trabajaban constantemente en el mismo archivo fuente (un formulario de "dios" de VB.NET). Esperaríamos a que alguien más terminara su trabajo y liberara el bloqueo exclusivo (VSS), y luego la siguiente persona en el orden jerárquico bloquearía inmediatamente el archivo para aplicar sus cambios. Esto llevó una eternidad porque tuvieron que reintegrar todo su trabajo en el nuevo código que solo podían ver en ese momento. Como yo era el chico nuevo, estaba al final de la jerarquía y NUNCA se me permitió verificar los cambios en mi código. Eventualmente fui con el director / gerente del proyecto y sugerí que se me encomendara otra parte de la funcionalidad de la aplicación. Este proyecto finalmente se autodestruyó, pero la mayoría de nosotros nos fuimos cuando nos dimos cuenta de que era inevitable. Tenga en cuenta que el uso de la integración de VSS fue una parte crucial de esta falla, también, ya que obliga a las primeras adquisiciones de ese valioso bloqueo de archivos.
Por lo tanto, un proyecto bien organizado casi nunca debe dar como resultado que dos personas trabajen en la misma parte del mismo archivo fuente al mismo tiempo. Por lo tanto, no hay necesidad de bloqueo exclusivo.
Otro de esos problemas más grandes es poner archivos binarios en control de fuente. Las herramientas de control de origen no están diseñadas para manejar binarios, y eso es algo bueno. Los binarios requieren un tratamiento diferente y las herramientas de control de origen no pueden respaldar ese tratamiento especial. Los binarios deben administrarse como un todo, no como partes (líneas). Los binarios tienden a ser mucho más estables / inalterables. Los binarios tienden a necesitar versiones explícitas diferentes del control de versiones de código fuente, a menudo con múltiples versiones disponibles simultáneamente. Los binarios a menudo se generan a partir de la fuente, por lo que solo se debe controlar la fuente (y los scripts de generación). Consulte los repositorios de Maven para obtener un diseño de almacenamiento binario (pero no use Maven, use Apache Ivy).
Cuando estoy en línea, parece que todos han coincidido en que usar el exclusivo flujo de trabajo de bloqueo en el control de la fuente es algo malo. Todos los nuevos sistemas de control de revisiones que veo parecen estar diseñados para editar y fusionar flujos de trabajo, y muchos ni siquiera admiten bloqueos exclusivos.
Sin embargo, todas las personas con las que trabajo son de la opinión de que los bloqueos exclusivos son "imprescindibles" para cualquier sistema de control de fuente, y trabajar de otra manera sería una pesadilla. Incluso las contrataciones recientes de otras compañías parecen venir con esta idea.
Mi pregunta no es quién tiene razón. Estoy bastante seguro de qué respuesta llegaría a eso. Mi pregunta es, ¿de verdad hay algún debate sobre este asunto? ¿Hay un campamento honesto de "bloqueo profesional" que pueda ser un caso serio? ¿Se está realizando algún trabajo para avanzar en el arte del control de revisiones basado en el modelo de bloqueo? ¿O están bloqueando fanáticos azotando un caballo muerto?
EDITAR: Las respuestas hasta ahora han hecho un buen trabajo al explicar por qué los bloqueos exclusivos son una buena característica para usar ocasionalmente. Sin embargo, estoy hablando de promover un flujo de trabajo donde se usan cerraduras exclusivas para todo .
En un proyecto de código abierto como un juego, tiene sentido mantener las imágenes bajo control de revisión, y es bueno poder bloquearlas (Subversion lo admite). Para los archivos de origen, es mejor ingresar al flujo de trabajo de fusión de edición. No es difícil y aumenta la productividad en mi experiencia.
Me gusta tener la opción de bloquear de forma exclusiva algunos archivos.
Es necesario tener un bloqueo exclusivo, por ejemplo, para archivos binarios.
También es semi-necesario para algunos archivos no binarios generados por máquina (por ejemplo, para archivos de proyectos de Visual Studio, que no se "combinan" para nada si alguna vez hay dos cambios paralelos que fusionar).
Si crees que las fusiones son difíciles (y aunque hemos recorrido un largo camino, pueden ser en algunas circunstancias), y no tienes programadores que frecuentemente quieran editar el mismo archivo, el bloqueo exclusivo no es necesariamente tan malo.
Yo no los usaría en un proyecto de código abierto, obviamente, pero en el mundo corporativo donde las reglas son más estrictas y se puede acercar a un chico y decir "¿puedo romper el candado?", Da visibilidad de lo que las personas son trabajar y evitar conflictos para que no tengan que resolverse más tarde.
Si dos personas realmente necesitan trabajar en un archivo al mismo tiempo, a menudo puede bifurcar ese archivo, y siempre que la herramienta aclare que esa rama debe fusionarse de nuevo, puede hacerlo y resolver cualquier conflicto, luego .
Dicho esto, no creo que tenga que volver a trabajar en un mundo exclusivo de bloqueo.
Si está acostumbrado al bloqueo exclusivo, entonces es difícil adoptar el flujo de trabajo de edición de fusión.
El bloqueo exclusivo tiene sus ventajas, especialmente para los archivos binarios (imágenes, videos, ...) que no se pueden fusionar automáticamente o no se pueden combinar.
Pero: la necesidad de bloqueo exclusivo siempre indica otro problema: buena comunicación entre las personas que trabajan en el proyecto. El bloqueo exclusivo proporciona un reemplazo deficiente: les dice a los usuarios que alguien más ya está trabajando en ese archivo en particular, algo que deberían saber sin usar un sistema de control de versiones.
Dado que hay mejores formas de ayudar con la comunicación entre los miembros del equipo, ¿la mayoría (todos) de los sistemas de control de versión ya no implementan el bloqueo exclusivo o simplemente una versión reducida (es decir, bloqueo, pero tal que esos bloqueos no se aplican).
No es tarea de un sistema de control de versiones ayudar con la comunicación.
Dirigiendo tus comentarios de edición.
Incluso RCS y SCCS (el abuelo VCS para la mayoría de lo que se ejecuta en Unix / Linux en la actualidad) permiten el acceso de edición simultánea a los archivos, y no me refiero a ramas separadas. Con SCCS, podría hacer '' get -k SCCS/s.filename.c '' y obtener una copia editable del archivo, y podría usar una opción ('' -p '' IIRC) para obtener el resultado estándar. Podrías hacer que otras personas hagan lo mismo. Luego, cuando llega el momento de registrarse, debe asegurarse de comenzar con la versión correcta o realizar una fusión para tratar los cambios desde que se recopiló su versión inicial, etc. Y ninguna de estas comprobaciones se automatizó, y los conflictos no se manejaron o marcaron automáticamente, y así sucesivamente. No dije que fuera fácil; solo que se podría hacer. (Según este esquema, las cerraduras solo se mantendrían durante un breve período de tiempo, mientras que una verificación / fusión estaba en progreso. Todavía tiene cerraduras; SCCS las requiere y RCS se puede compilar con un estricto bloqueo, pero solo para abreviar). duraciones, pero es un trabajo duro, nadie lo hizo porque es un trabajo tan difícil).
Los VCS modernos manejan la mayoría de los problemas de manera automática o casi automática. Esa es su gran fortaleza en comparación con los sistemas ancestrales. Y debido a que la fusión es fácil y casi automática, permite diferentes estilos de desarrollo.
Todavía me gusta encerrarme. El sistema de trabajo principal que uso es (IBM Rational) Atria ClearCase; para mi propio desarrollo, utilizo RCS (habiendo renunciado a SCCS alrededor de Y2K). Ambos usan bloqueo. Pero ClearCase tiene buenas herramientas para hacer fusiones, y hacemos una buena cantidad de eso, sobre todo porque hay al menos 4 líneas de código activas en el producto en el que trabajo (4 versiones principales, eso es). Y las correcciones de errores en una versión a menudo se aplican a las otras versiones, casi al pie de la letra.
Por lo tanto, el VCS con bloqueo solo no tiene instalaciones de fusión lo suficientemente buenas como para alentar el uso de la edición concurrente de archivos. Los VCS más modernos tienen mejores instalaciones de fusión (y también de bifurcación) y, por lo tanto, no tienen una necesidad tan fuerte de bloqueo durante más tiempo (lo suficiente para hacer que las operaciones en el archivo (o archivos en los sistemas más avanzados) sean atómicas) .
Aquí está mi $ 0.02.
Locking es una antigua escuela de pensamiento para el Código de texto. Una vez que los programadores usan la fusión un par de veces, aprenden y generalmente les gusta su poder.
Los casos válidos para los bloqueos todavía existen.
- Alteraciones gráficas. El 99% de las veces no puedes fusionar 2 personas trabajando en el mismo gráfico.
- Actualizaciones binarias
- A veces, el código puede ser lo suficientemente complejo / simple como para justificar que solo 1 persona trabaje en él a la vez. En este caso, es una opción de administración de proyectos utilizar una función.
Los argumentos para bloquear son realmente malos. Básicamente dicen: nuestras herramientas son tan malas que no pueden fusionarse, así que trabajamos.
En mi experiencia, a menudo es necesario que dos personas trabajen en el mismo archivo al mismo tiempo. (Hay, presumiblemente, tiendas donde esto no sucede, pero tengo bastante experiencia variada para aprovechar).
En estos casos, es necesario que ambas personas obtengan copias del original, hagan su trabajo y fusionen sus cambios. En los VCS sin bloqueo, esto se hace de forma automática y precisa en su mayor parte.
Con un VCS bloqueado, lo que sucede es que una persona obtiene el bloqueo. Si esa persona termina primero, genial; si no, la otra persona tiene que esperar antes de poder introducir cambios. Algunas veces es necesario hacer una corrección rápida de errores mientras que alguien está en medio de un largo proceso de cambio, por ejemplo. Una vez que la segunda persona tiene el bloqueo, la segunda persona debe fusionar los cambios, normalmente de forma manual, y registrar la nueva versión. En varias ocasiones, he visto que los cambios en la primera persona cayeron por completo, ya que la segunda persona no se molestó con la fusión manual. Con frecuencia, esta fusión se realiza apresuradamente, ya sea por disgusto por el trabajo o por simple presión de tiempo.
Por lo tanto, si dos personas necesitan trabajar en el mismo archivo al mismo tiempo, un VCS sin bloqueo casi siempre es mejor.
Si esto no aparece, y dos personas nunca necesitan trabajar en el mismo archivo al mismo tiempo, no importa cuál use.
En mi opinión, la razón principal por la que las personas usan el bloqueo exclusivo es su simplicidad y, para ellos, la falta de riesgo.
Si tengo acceso exclusivo a un archivo, no tendré que tratar de comprender a alguien más, los cambios en el mismo archivo. No tengo que arriesgarme a hacer los cambios y luego tener que fusionarme con alguien más cuando realizo el registro.
Si tengo un bloqueo exclusivo en los archivos que estoy cambiando, entonces sé que cuando me registre, podré registrar un conjunto de cambios coherente; es más simple para mí hacer esto.
El otro aspecto de la fusión (especialmente la fusión automática) es el potencial de los problemas de regresión. Sin buenas pruebas automatizadas, cada vez que realice una fusión automática, puede tener problemas. Al menos si tiene un bloqueo exclusivo en algo, se asegura de que alguien esté mirando el código antes de que se registre. Esto, para algunos, reduce el riesgo.
Lo que el bloqueo exclusivo elimina es el paralelismo potencial de los cambios. No puedes tener dos personas trabajando en un archivo.
El modelo de fuente abierta (muchas personas de todo el mundo colaboran en diferentes cosas) ha promovido la idea de que el bloqueo es malo, pero realmente funciona para algunos equipos. Evita problemas reales. No digo que estos problemas no se puedan superar, pero requiere un cambio en el comportamiento de las personas; si desea cambiar a un modelo sin bloqueo, debe convencerlos de que cambien a una forma de trabajo que pueda parecerles más difícil y, en realidad, (en su opinión) puede aumentar el riesgo de causar regresiones.
Personalmente, prefiero no usar bloqueos, pero puedo ver por qué a algunas personas no les gusta.
Interesante pregunta. Para mí, el problema no es tanto si bloquear, sino cuánto tiempo bloquear. En esta tienda, soy una minoría de uno, porque me gusta fusionarme. Me gusta saber qué han hecho otras personas con el código. Entonces, lo que hago es:
Siempre trabaje en una copia local del árbol fuente.
Ejecute Windiff a menudo contra el código "oficial" y, si es necesario, fusione los cambios en mi copia local. Para la fusión, uso un viejo Emacs (Epsilon) y tengo el comando compare-buffers vinculado a una tecla de acceso rápido. Otra tecla dice "hacer el resto de esta línea como la del otro archivo", porque muchos cambios son pequeños.
Cuando estoy listo para registrar los cambios, Windiff me dice qué archivos necesito bloquear, registrar y desbloquear. Así que los mantengo cerrados el menor tiempo posible, como minutos.
Entonces, cuando Fearless Leader dice "¿Has registrado tu código?" la respuesta es "No tengo ninguna salida".
Pero como dije, soy una minoría de uno.
Un poco tarde para esta discusión, pero para cualquiera que haya leído y digitado el Código sólido de escritura de Steve Maguire, un punto central es hacer que sus herramientas detecten e identifiquen tantos problemas como sea posible.
Un compilador no se cansa después de 12 o más horas seguidas y se olvida de emitir un error de sintaxis. Pero es bastante fácil olvidar un paso manual de iniciar una comunicación y pagarla más tarde.
Si necesita controlar la versión de un archivo binario, entonces necesita alguna forma de bloqueo para evitar, o al menos advertir, una sobrescritura accidental. Debe ser una característica fundamental de cualquier VCS incluso distribuido. Para utilizar dicha función en un DVCS puede requerir la creación de un repositorio central, pero ¿es eso tan malo? Si utiliza un DVCS en cualquier tipo de entorno corporativo, tendrá un repositorio central para garantizar la continuidad del negocio.