¿Cuáles son las ventajas de un control de versión distribuida para un equipo que efectivamente nunca se distribuye?

Question

Al trabajar de forma remota, nuestro equipo solo tiene acceso a nuestro código fuente desde el escritorio remoto en nuestras PC de oficina, por lo que nunca trabajamos en modo fuera de línea. ¿Un sistema de control de versiones distribuidas como Mercurial o Git todavía nos da ventajas sobre nuestra configuración de Subversion centralizada actual? Si es así, ¿Que son? ¿Hay inconvenientes o dificultades? He leído en numerosos lugares que el cambio al control de versiones distribuidas requiere un cambio de pensamiento. ¿Alguien puede explicar lo que debe cambiar a este respecto?

Answer 1

Recomendaría HgInit como una explicación muy completa de cómo un conjunto de herramientas descentralizado mejora svn. También lo ayudará a comprender las diferencias conceptuales.

Una de las grandes mejoras que me gustaría destacar es la noción de seguimiento de fusión. Subversion no tenía esta característica hasta 1.5, y con la diferencia en la forma en que trata las revisiones y las sucursales, probablemente nunca será tan buena como pueden ser las herramientas descentralizadas. A nadie le gustan las fusiones. Podría reducir tanto ese dolor como puedas. También vea: Why is branching and merging easier in Mercurial than in Subversion?.

El mayor cambio en mi forma de pensar al hacer el cambio desde la subversión fue superar la idea de que el historial es estrictamente lineal, y la bifurcación no es más que copiar el código a otro directorio. Tenga en cuenta que en Git y Mercurial, no se puede extraer un subdirectorio del repositorio. No verá 'git checkout http://github.com/project/branches/v2.0' ni nada. Eric Sink escribió una muy buena explicación de la diferencia en la forma en que se almacena la historia. Recomiendo taking a look.

Answer 2

Como se explica en la differences between DVCS and CVCS (centralizada VCS), las principales ventajas son:

• commits locales (que pueden comprometer más a menudo en las ramas privadas, a continuación, limpiar el historial usted quiere empujar a otros repos)
• publication process (se tira desde múltiples repositorios, o estableció rápidamente repos intermedios para empujar a, donde se puede hacer tareas intermedias como las pruebas de integración continua)

Este último punto requiere el mos "cambiar de pensar" y es un poco aterrador ("Puedo sacar de cualquier repo ?!")
Pero una vez que se da cuenta de los beneficios, realmente puede tener ciclos de desarrollo más productivos porque puede monitorear (por obteniendo compromisos de tus compañeros) el desarrollo de algunos de tus colegas. Si están desarrollando una función que necesita, puede comenzar a integrarla antes.
(La cosa a recordar con una DVCS es que es no impide que la configuración de un acuerdo de recompra "central", para otros desarrolladores para tirar de)

En cuanto a la integración continua, en lugar de empujar directamente desde tu repositorio de un servidor central a cargo de CI, puede pasar a local repo en su escritorio, que ejecutará todas las pruebas, antes de pasar automáticamente (si es "verde") el código a un repositorio "central".
Es tan eficaz que ahora se puede empujar al repositorio central de funcionario de un código que "nunca se rompe la acumulación", lo que hace su servidor CI bastante inútil;)

Answer 3

Las máquinas de desarrollo podrían estar al lado de la otra, pero el código fuente todavía se distribuye entre ellos. Que las máquinas estén cerca físicamente no tiene importancia para gestionar los cambios en el código fuente realizados por diferentes desarrolladores.