Mi empresa actualmente utiliza Subversion, CVS, Mercurial y git.
Cuando comenzamos hace cinco años elegimos CVS, y todavía lo usamos en mi división para nuestra rama principal de desarrollo y liberación. Sin embargo, muchos de nuestros desarrolladores usan Mercurial individualmente como una forma de tener puntos de control privados sin el dolor de las ramas de CVS (y particularmente fusionándolos) y estamos empezando a usar Mercurial para algunas sucursales que tienen hasta 5 personas. Hay una buena posibilidad de que finalmente abandonemos CVS en otro año. Nuestro uso de Mercurial ha crecido orgánicamente; algunas personas ni siquiera lo tocan, porque están contentos con CVS. Todo el que ha probado Mercurial ha terminado siendo feliz con él, sin mucha curva de aprendizaje.
Lo que funciona muy bien para nosotros con Mercurial es que nuestros servidores de integración continua (fabricados en casa) pueden monitorear los repositorios Mercurial del desarrollador, así como también la línea principal. Entonces, la gente se compromete con su repositorio, obtiene nuestro servidor de integración continua para verificarlo y luego publica el conjunto de cambios. Admitimos muchas plataformas, por lo que no es factible realizar un nivel decente de controles manuales. Otra victoria es que las fusiones son a menudo fáciles, y cuando son difíciles, usted tiene la información que necesita para hacer un buen trabajo en la fusión. Una vez que alguien obtiene la versión fusionada para trabajar, puede impulsar sus conjuntos de cambios de fusión y luego nadie más tiene que repetir el esfuerzo.
El mayor obstáculo es que debe volver a conectar los cerebros de sus desarrolladores y gerentes para que escapen del modelo de rama lineal única. El mejor medicamento para esto es una dosis de Linus Torvalds diciéndole que es stupid and ugly si usa SCM centralizado. Las buenas herramientas de visualización de historial ayudarían pero aún no estoy satisfecho con lo que está disponible.
Mercurial y CVS nos funcionan bien con desarrolladores que usan una combinación de Windows, Linux y Solaris, y no he notado problemas con las zonas horarias. (En realidad, esto no es muy difícil, solo usa segundos de época internamente, y espero que todos los principales sistemas SCM lo hagan bien).
Fue posible, con un esfuerzo considerable, importar nuestra historia de CVS principal a Mercurial. Hubiera sido más fácil si las personas no hubieran introducido deliberadamente casos de esquina en nuestra historia de CVS principal como una forma de probar las herramientas de migración de historial. Esto incluyó la fusión de algunas ramas de Mercurial en el historial de CVS, por lo que el proyecto parece que se estaba utilizando desde el primer día.
Nuestro grupo de diseño de silicio eligió Subversion. Son principalmente ocho zonas horarias alejadas de mi oficina, e incluso a través de una línea dedicada bastante buena entre nuestras oficinas. Las comprobaciones de sustitución son dolorosas, pero factibles. Una gran ventaja de los sistemas centralizados es que puedes verificar grandes binarios (por ejemplo, lanzamientos de proveedores) sin hacer que todos los repositorios distribuidos sean enormes.
Utilizamos git para trabajar con kernel de Linux. Git sería más adecuado para nosotros una vez que la versión nativa de Windows esté madura, pero creo que el diseño de Mercurial es tan simple y elegante que nos quedaremos con él.
¿Cómo hace DVCS menos conflictos de combinación? Y si fracasas en una fusión en un VCS normal, ¿no puedes hacer una copia de seguridad y hacerlo de nuevo y registrar ese resultado? –
A DVCS hace que las fusiones sean más fáciles de administrar porque cada check-in individual tiende a ser más pequeño, ya que acaba haciéndolo localmente cuando termina. Eso le da al sistema una visión más detallada de cómo cambiaron las cosas, lo que facilita la automatización de la fusión. Con un VCS normal, no puede hacer una copia de seguridad ni rehacer la fusión de la misma manera porque el estado de su código nunca se grabó en ningún lugar. No está en ningún registro. Así que, aunque puede recuperar el estado del repositorio, es probable que sus cambios se pierdan. En un DVCS, puede confirmar sus cambios primero, de modo que ambos lados de la fusión tengan un historial completo. – tghw
La otra forma en que un DVCS evita conflictos de fusión es que tiene antecedentes de fusiones anteriores, por lo que si un conjunto de cambios ya se fusionó, el sistema no intenta fusionarlo de nuevo, mientras que los sistemas VCS normales como Subversion incluirán ese conjunto de cambios en el fusionarse, aumentando las posibilidades de un conflicto. – tghw