version control - usados - ¿Por qué el control de fuente distribuida se considera más difícil?
sistemas de control de versiones (9)
Parece bastante común (por lo menos aquí) que la gente recomiende SVN a los recién llegados al control de fuente porque es "más fácil" que una de las opciones distribuidas. Como usuario muy casual de SVN antes de cambiar a Git para muchos de mis proyectos, descubrí que este no era el caso en absoluto.
Es conceptualmente más fácil configurar un repositorio DCVS con git init (o lo que sea), sin el problema de tener que configurar un repositorio externo en el caso de SVN.
Y la funcionalidad base entre SVN, Git, Mercurial, Bazaar todos usan comandos esencialmente idénticos para confirmar, ver diffs, y así sucesivamente. Que es todo lo que un recién llegado realmente va a estar haciendo.
La pequeña diferencia en la forma en que Git requiere que los cambios se agreguen explícitamente antes de comprometerse, en oposición a la política de "comprometer todo" de SVN, es conceptualmente simple y, a menos que esté equivocado, ni siquiera es un problema al usar Mercurial o Bazar.
Entonces, ¿por qué SVN se considera más fácil? Yo diría que esto simplemente no es verdad.
Creo que el conjunto de herramientas para SVN es mucho más amplio, por lo que podría sentarse y enseñar a la gente (TortoiseSVN, RapidSVN, etc.) incluso si no tenían mucha idea conceptual de cómo funcionaba el repositorio. También es relativamente fácil obtener SVN alojado para usted (con trac, por ejemplo) sin necesidad de saber nada. Los distribuidos no han tenido este respaldo todavía y estoy seguro de que las opiniones cambiarán cuando lo hagan.
Creo que es conceptualmente más simple pensar en un repositorio centralizado donde cada desarrollador confía su trabajo frente a copias múltiples de todo el repositorio, ninguna de las cuales representa la ''verdad''. Como la mayoría de los desarrolladores están familiarizados con la noción de un modelo de cliente-servidor y una base de datos back-end, este es un concepto natural.
Por supuesto, la misma fuerza de los sistemas distribuidos de control de fuentes es que no tienen que adherirse a este modelo, pero para un recién llegado, parece más fácil de entender.
DVCS actualmente no tiene buenos clientes de escritorio. A pesar de lo que la mayoría de la gente dice, los sistemas de control de versiones pueden ser bastante difíciles de usar correctamente, por lo que un buen cliente de escritorio puede ser de gran ayuda, y aquí TortoiseSVN es excelente.
Si usa el control de versión solo para usted, SVN probablemente sea más difícil, ya que la configuración es más difícil. Sin embargo, si desea trabajar con múltiples desarrolladores en la web, un control del lado del servidor tiene ventajas:
- Usted tiene un lugar central, que siempre tiene la fuente oficial del estado de la técnica, siendo el servidor SVN
- Como todo el mundo siempre fusiona sus cambios con un servidor central, hay mucho menos colisiones y mucha menos fijación manual de colisiones.
- Usted tiene control central sobre la fuente
- Tienes un número de revisión oficial en lugar de un hash de revisión, es el mismo entre todos los desarrolladores y muestra el progreso oficial (es un número de conteo progresivo, a diferencia de un hash, que es solo una huella digital de identidad, para que puedas ver qué código es más nuevo o más viejo, solo por este número
Un sistema de control de versiones distribuido es A Very Good Thing (tm), pero creo que la principal barrera para la adopción es educar a los usuarios sobre las nuevas posibilidades que ofrece un nuevo SCM.
Esto, junto con una cantidad de herramientas de interfaz de usuario a menudo sin brillo (implementaciones de tortuga a medio terminar, etc.), trae una mirada en blanco a la vista de muchos compañeros de trabajo que desde hace mucho tiempo prefirieron la línea de comandos por una buena herramienta de interfaz de usuario.
Además, con herramientas como CVS encuentro que las personas aborrecen la bifurcación y la fusión porque realmente no quieren estar atrapados un día entero haciendo fusiones en tres direcciones, a menudo sin estar seguros de cuál sería la fusión correcta para hacer.
Mi punto es: comience diciéndole a la gente lo que gana (no solo "oye este nuevo juguete genial"), y prepárelos al hecho de que usar una línea de comando ES el camino a seguir y esa frecuente bifurcación de tiempo constante es algo bueno .
Muchos sistemas como mercurial vienen con un sistema completo de cola de parches, lo que significa que desde el punto de vista de la Integración Continua, usted sabe que todo lo que entra en producción ha sido aprobado por QA. Cosas como esta son difíciles de hacer correctamente con CVS o SVN.
Con Mercurial las personas tendrían repositorios privados para su trabajo actual y todos los desarrolladores compartirían un árbol desarrollador en un servidor. El sistema CI supervisa el árbol de desarrolladores y extrae todos los cambios, construcciones y realiza pruebas de unidad. Si todo pasa, propaga los cambios a un árbol de pruebas desde donde se crea un entregable para las personas de control de calidad. Cada conjunto de cambios que se agrega recibe un token. Cuando QA considera que una característica está completa, anotan el árbol de prueba con este token y los conjuntos de cambios asociados se propagan automáticamente al árbol de producción.
Al utilizar este enfoque, nunca comprometerá nada manualmente con la rama de producción o la rama de prueba. Más bien, el estado del código y el cierre de sesión de QA determina el contenido de su rama de producción,
Yo argumentaría que configurar un repositorio con un DVCS es prácticamente más fácil, pero conceptualmente más difícil. Después de todo, con un VCS centralizado los usuarios no configuran su propio repositorio, simplemente crean una cuenta en Assembla o tienen el repo configurado para ellos.
Nos esforzamos por hacerlo lo más fácil posible en Codice, pero siempre es un poco más difícil de explicar, por supuesto, depende de la audiencia.
Para los proyectos OSS y los equipos pequeños, especialmente las personas que trabajan en sus computadoras portátiles y se mudan aquí y allá, trabajan en casa, en avión a veces, y así sucesivamente, es bastante fácil. Pero, cada vez que hablas con corporaciones / empresas, se entusiasman con su rol de sitios múltiples, pero no con la distribución a primera vista. Todo depende de si el grupo tiene una mayoría de desarrolladores avanzados o no.
Es marketing deficiente , así de simple. Demasiadas presentaciones de DVCS se centran en la línea de comando y dicen "wow, ¿no es fantástico, puedes fusionar simplemente tecleando hg merge" ignorando por completo el hecho de que muchas personas (especialmente en Windows) están aterrorizadas por la línea de comando. Sí, Joel Spolsky, estoy viendo tu propio hginit.com aquí. ¡Necesitamos una versión de TortoiseHg por favor!
Tal vez fue el caso hace dos años que tuvieron implementaciones de GUI pobres, pero han avanzado a pasos agigantados recientemente. TortoiseHg ahora se encuentra en la versión 1.0, y si bien puede no ser algo para destacar visualmente, es bastante sólido, estable y fácil de usar. TortoiseGit también es sólido como una roca y hace un gran trabajo de abstracción de todas las complejidades de la línea de comandos de git.
Svn obliga a una sola línea de trabajo. Puedes comprometerte o no puedes. Al tener experiencias similares, no creo que Hg o Git sean difíciles de usar, sin embargo, trabajo en un equipo que parece tener pesadillas para usarlos.
El concepto completo de autorrubicación, jefes múltiples, cuándo y cuándo no fusionarse los elude por completo, sin mencionar que tienen problemas para liberarse de la mentalidad "commit / checkout with $ somecore" que lleva a una completa confusión cuando ven impulsos entre 2 copias desprotegidas.
(Tuve un problema por un tiempo en el que alguien fusionó repetidamente 2 sucursales que no debían fusionarse porque no podían captar el concepto).
Sin embargo, las mismas personas que tienen problemas con el SCMS distribuido me hicieron formular esta pregunta.
editar / nota La mayor diferencia de Mercurials que he notado vs git que hace que mercurial sea más difícil de usar para los novatos es el comportamiento predeterminado de mercurials para push / pull es como hacer git push --all / git pull --all, que puede propagar ramas privadas y agregar mucha confusión (especialmente cuando aparece una nueva rama, mercurial se congela con miedo y te pregunta cómo manejarla en lugar de simplemente seguir en camiones), así como la herramienta predeterminada de fusión / resolución de conflictos en mac acaba de aplastar a un conjunto de cambios a ciegas.