¿Utiliza el control de versión distribuida?

Question

Me gustaría saber de personas que utilizan el control de versiones distribuidas (también conocido como control de versiones distribuidas, control de versiones descentralizadas) y cómo lo están encontrando. ¿Qué estás usando, Mercurial, Darcs, Git, Bazaar? ¿Todavía lo estás usando? Si ha utilizado las funciones cliente/servidor en el pasado, ¿lo está encontrando mejor, peor o simplemente diferente? ¿Qué podría decirme que me haría subir al carro? O salte para el caso, me interesaría saber de personas con experiencias negativas también.

Actualmente estoy buscando reemplazar nuestro sistema de control de fuente actual (Subversion) que es el ímpetu para esta pregunta.

Estaría especialmente interesado en cualquiera que lo haya usado con compañeros de trabajo en otros países, donde sus máquinas no estén encendidas al mismo tiempo, y su conexión sea muy lenta.

Si no está seguro de qué versión distribuida de control es, aquí hay un par de artículos:

Intro to Distributed Version Control

Wikipedia Entry

Answer 1

He estado usando Mercurial tanto en el trabajo como en mis propios proyectos personales, y estoy muy contento con él. Las ventajas que veo son:

1. Control de versiones local. A veces estoy trabajando en algo, y quiero mantener un historial de versiones, pero no estoy listo para enviarlo a los repositorios centrales. Con VCS distribuido, puedo comprometerme con mi repositorio local hasta que esté listo, sin ramificaciones. De esa forma, si otras personas hacen los cambios que necesito, aún puedo obtenerlos e integrarlos en mi código. Cuando estoy listo, lo empujo a los servidores.
2. Menos conflictos de combinación. Todavía suceden, pero parecen ser menos frecuentes, y son un riesgo menor, porque todo el código se registra en mi repositorio local, por lo que incluso si fallo la fusión, siempre puedo hacer una copia de seguridad y volver a hacerlo.
3. Repositorios separados como sucursales. Si tengo un par de vectores de desarrollo ejecutándose al mismo tiempo, puedo hacer varios clones de mi repositorio y desarrollar cada característica de forma independiente. De esa forma, si algo se desecha o se resbala, no tengo que sacar las piezas. Cuando están listos para irse, simplemente los fusiono.
4. Velocidad. Mercurial es mucho más rápido para trabajar, sobre todo porque la mayoría de sus operaciones comunes son locales.

Por supuesto, como en cualquier sistema nuevo, hubo algo de dolor durante la transición. Tienes que pensar en el control de versiones de forma diferente a como lo hacías cuando usabas SVN, pero en general creo que vale mucho la pena.

Answer 2

El uso de Subversion con SourceForge y otros servidores a través de una serie de diferentes conexiones con equipos medianos y está funcionando muy bien.

Answer 3

El uso de Subversion

Subversion no se distribuye, por lo que me hace pensar que necesito un enlace de wikipedia en caso de que la gente no está seguro de lo que estoy hablando :)

Answer 4

No

el uso de control de código fuente distribuido a mí mismo, pero tal vez estas preguntas y respuestas relacionadas darle algunas ideas:

• Distributed source control options
• Why is git better than Subversion

Answer 5

Soy un gran defensor de control de código fuente centralizada para un montón de razones, pero lo hice tratar Bitkeeper en un proyecto brevemente. Quizás después de años de utilizar un modelo centralizado en un formato u otro (Perforce, Subversion, CVS), descubrí que el control de fuente distribuida es difícil de usar.

Soy de la opinión de que nuestras herramientas nunca deberían obstaculizar el trabajo real; deberían hacer el trabajo más fácil. Entonces, después de algunas experiencias impactantes, salí de apuros. Aconsejaría hacer algunas pruebas realmente duras con tu equipo antes de balancear el barco porque el modelo es muy diferente de lo que la mayoría de los desarrolladores probablemente estén acostumbrados en el mundo de SCM.

Answer 6

Me encanta Git, especialmente con GitHub. Es muy bueno poder comprometerse y retroceder localmente. Y las fusiones, aunque no triviales, no son terriblemente difíciles, y mucho más avanzadas que cualquier cosa que Svn o CVS puedan hacer.

Answer 7

En mi lugar de trabajo cambiamos a Git de CVS hace aproximadamente dos meses (la mayoría de mi experiencia es con Subversion). Si bien hubo una curva de aprendizaje relacionada con familiarizarse con el sistema distribuido, he descubierto que Git es superior en dos áreas clave: la flexibilidad del entorno de trabajo y la fusión.

No tengo que estar en nuestra VPN, o incluso tener conectividad de red, para tener acceso a las capacidades de control de versiones completas.Esto significa que puedo experimentar con ideas o realizar refactorizaciones grandes donde sea que me encuentre cuando llegue la urgencia, sin tener que acordarme de controlar ese gran compromiso que he acumulado o preocuparme por no poder revertir cuando hago un desastre.

Como las fusiones se realizan en el lado del cliente, son mucho más rápidas y menos propensas a errores que iniciar una fusión del lado del servidor.

Answer 8

Personalmente uso el sistema de control de fuente Mercurial. Lo he usado por un poco más de un año en este momento. En realidad fue mi primera experiencia con un VSC.

Probé Git, pero nunca lo presioné porque descubrí que era demasiado para lo que necesitaba. Mercurial es realmente fácil de usar si eres un usuario de Subversion ya que comparte muchos comandos con él. Además, encuentro que la administración de mis repositorios es realmente fácil.

tengo 2 formas de compartir el código con la gente:

• que comparten un servidor con un compañero de trabajo y mantenemos un acuerdo de recompra principal de nuestro proyecto.
• Para algunos proyectos OSS trabajo en, creamos parches de nuestro trabajo con Mercurial (exportación Hg) y la maintener del proyecto acaba de aplicarlos en el repositorio (importación Hg)

realmente fácil trabajar con él , sin embargo, muy poderoso. Pero, en general, elegir un VSC realmente depende de las necesidades de nuestro proyecto ...

Answer 9

Antes, al apagar las estaciones de trabajo Sun para el desarrollo de sistemas integrados, estábamos usando la solución TeamWare de Sun. TeamWare es una solución de distribución completa que utiliza SCCS como el sistema de revisión de archivos del repositorio local y luego lo envuelve con un conjunto de herramientas para manejar las operaciones de fusión (realizadas a través del cambio de nombre de la rama) a los repositorios centralizados de los cuales puede haber muchos. De hecho, debido a que se distribuye, realmente no existe un repositorio maestro per se '(excepto por convención si así lo desea) y todos los usuarios tienen sus propias copias de todo el árbol fuente y las revisiones. Durante las operaciones de "devolución", la herramienta de fusión que utiliza difs de 3 vías clasifica algorítmicamente qué es qué y le permite combinar los cambios de diferentes desarrolladores que se han acumulado a lo largo del tiempo.

Después de cambiar a Windows para nuestra plataforma de desarrollo, terminamos cambiando a AccuRev. Si bien AccuRev, debido a que depende de un servidor centralizado, no es realmente una solución distribuida, lógicamente desde un modelo de flujo de trabajo se acerca mucho. Cuando TeamWare haya tenido copias completamente separadas de todo en cada cliente, incluidas todas las revisiones de todos los archivos, en AccuRev esto se mantiene en la base de datos central y las máquinas del cliente local solo tienen la versión actual de archivos planos para su edición local. Sin embargo, estas copias locales se pueden versionar a través de la conexión del cliente al servidor y se pueden rastrear por separado de cualquier otro cambio (p. Ej .: ramas) creado implícitamente por otros desarrolladores

Personalmente, creo que el modelo distribuido implementado por TeamWare o el tipo de El modelo híbrido implementado por AccuRev es superior a las soluciones completamente centralizadas. La razón principal de esto es que no existe la noción de tener que extraer un archivo o tener un archivo bloqueado por otro usuario. Además, los usuarios no tienen que crear o definir las ramas; las herramientas hacen esto para ti implícitamente. Cuando hay equipos más grandes o equipos diferentes que contribuyen o mantienen un conjunto de archivos fuente, esto resuelve las colisiones relacionadas con el bloqueo generado y permite que los cambios de código se coordinen más al nivel del desarrollador, que en última instancia debe coordinar los cambios. En cierto sentido, el modelo distribuido permite un "bloqueo" de grano mucho más fino en lugar del bloqueo de granulado de campo instituido por los modelos centralizados.

Answer 10

En el lugar donde trabajo, decidimos pasar de SVN a Bazaar (después de evaluar git y mercurial). Bazar fue fácil de empezar, con comandos simples (no como los 140 comandos que tiene git)

Las ventajas que vemos es la capacidad de crear ramas locales y trabajar en ellas sin molestar a la versión principal. Además de poder trabajar sin acceso a la red, hacer diffs es más rápido.

Un comando en bzr que me gusta es la extensión de la estantería. Si comienza a trabajar en dos partes de código lógicamente diferentes en un solo archivo y desea comprometer solo una pieza, puede usar la extensión de estantería para dejar de lado los otros cambios más adelante. En Git puedes hacer lo mismo jugando en el índice (área de preparación) pero bzr tiene una mejor IU.

La mayoría de las personas eran reacias a moverse ya que tienen que escribir dos comandos para confirmar y presionar (bzr ci + bzr push). También fue difícil para ellos entender el concepto de ramas y fusión (nadie usa ramas o las fusiona en svn).

Una vez que comprenda eso, aumentará la productividad del desarrollador. Hasta que todos entiendan eso, habrá un comportamiento incoherente entre todos.

Answer 11

He usado bazaar por un tiempo y ahora me encanta. Las ramificaciones triviales y la fusión de nuevo dan una gran confianza en el uso de ramas como deberían ser utilizadas. (Sé que las herramientas vcs centrales deberían permitir esto, pero las comunes, incluida la subversión, no permiten esto fácilmente).

bzr soporta bastantes diferentes workflows de solo, a través de trabajar como un repositorio centralizado a completamente distribuido. Con cada rama (para un desarrollador o una función) que se puede fusionar de forma independiente, las revisiones de código se pueden realizar por rama.

bzr también tiene un gran complemento (bzr-svn) que le permite trabajar con un repositorio de subversión. Puede hacer una copia del repositorio svn (que inicialmente demora un poco, ya que recupera todo el historial de su repositorio local). A continuación, puede crear sucursales para diferentes funciones. Si desea realizar una reparación rápida en el maletero a la mitad de su función, puede hacer una ramificación adicional, trabajar en eso y luego volver a fusionarse en el maletero, dejando la función de medio hecho intacta y fuera del tronco. Maravilloso. Trabajar contra la subversión ha sido mi principal uso hasta ahora.

Nota Solo lo he usado en Linux, y principalmente desde la línea de comandos, aunque debe funcionar bien en otras plataformas, tiene GUIs como TortoiseBZR y se está trabajando mucho en la integración con IDEs y similares.

Answer 12

Mi grupo en el trabajo está usando Git, y ha sido toda la diferencia en el mundo. Estábamos utilizando SCCS y una pila humeante de scripts csh para gestionar proyectos bastante grandes y complicados que compartían el código entre ellos (de todos modos, lo intentamos).

Con Git, el soporte de submódulos hace que todo esto sea fácil, y solo se necesita un mínimo de secuencias de comandos. Nuestro esfuerzo de ingeniería de lanzamiento ha ido mucho más allá porque las sucursales son fáciles de mantener y rastrear. Ser capaz de bifurcar y fusionar de manera económica realmente hace que sea razonablemente fácil mantener una sola colección de fuentes en varios proyectos (contratos), mientras que antes, cualquier interrupción al flujo típico de las cosas era muy, muy costosa. También hemos encontrado que la capacidad de script de Git es enorme plus, porque podemos personalizar su comportamiento a través de enganches o mediante scripts que hacen . git-sh-setup, y no parece una pila de kludges como antes.

A veces también tenemos situaciones en las que tenemos que mantener nuestro control de versiones en sitios distribuidos, no conectados a la red (en este caso, laboratorios seguros desconectados), y Git tiene mecanismos para manejarlo sin problemas (paquetes, los básicos mecanismo de clonación, parches formateados, etc.).

Algo de esto nos acaba de dejar a principios de los 80 y adoptamos algunos mecanismos modernos de control de versiones, pero Git "lo hizo bien" en la mayoría de las áreas.

No estoy seguro del alcance de la respuesta que está buscando, pero nuestra experiencia con Git ha sido muy, muy positiva.

Answer 13

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.

Answer 14

He estado utilizando darcs 2.1.0 y es ideal para mis proyectos. Fácil de usar. Me encantan los cambios en la selección de cerezas.

Answer 15

Han usado darcs en un gran proyecto (GHC) y para muchos proyectos pequeños. Tengo una relación de amor/odio con los darcs.

Ventajas: increíblemente fácil de configurar el repositorio. Muy fácil de mover los cambios entre los repositorios. Muy fácil de clonar y probar 'ramas' en repositorios separados. Es muy fácil hacer 'commits' en pequeños grupos coherentes que tengan sentido. Muy fácil cambiar el nombre de los archivos y los identificadores.

Desventajas: ninguna noción de historial --- no puede recuperar 'el estado de las cosas el 5 de agosto'. Nunca he descubierto cómo usar los darcs para volver a una versión anterior.

Deal-breaker: darcs no escala. Yo (y muchos otros) me he metido en un gran problema con GHC usando darcs. He tenido problemas con el uso de la CPU al 100% durante 9 días tratando de obtener 3 meses de cambios. Tuve una mala experiencia el verano pasado cuando perdí dos semanas tratando de hacer que Darcs funcionara y finalmente recurrí a reproducir todos mis cambios a mano en un repositorio prístino.

Conclusión: darcs es genial si quieres una forma simple y liviana de evitar dispararte en el pie para tus proyectos de hobby. Pero incluso con algunos de los problemas de rendimiento abordados en Darcs 2, todavía no es para cosas de fuerza industrial. Realmente no creeré en los darcs hasta que la tan cacareada 'teoría de parches' sea algo más que unas pocas ecuaciones y algunas buenas imágenes; Quiero ver una teoría real publicada en un lugar arbitrado. Ya pasó el tiempo.

Answer 16

Uso a Git en el trabajo, junto con uno de mis compañeros de trabajo. El repositorio principal es SVN, sin embargo. A menudo tenemos que cambiar de estación de trabajo y Git hace que sea muy fácil extraer los cambios de un repositorio local en otra máquina. Cuando trabajamos en equipo en la misma función, fusionar nuestro trabajo es fácil.

El puente git-svn es un poco inestable, porque cuando se registra en SVN reescribe todos los commits para agregar su comentario de git-svn-id. Esto destruye la agradable historia de las fusiones entre el repositorio de mi compañero de trabajo y una mina. Predigo que no usaríamos un repositorio central si cada miembro del equipo estuviera usando Git.

No dices en qué sistema operativo desarrollas, pero Git tiene la desventaja de que debes usar la línea de comando para obtener todas las características. Gitk es una buena guía para visualizar el historial de fusión, pero la fusión debe hacerse manualmente. Los complementos de Git-Gui y Visual Studio aún no están pulidos.

Answer 17

Estoy jugando con Mercurial para mis proyectos en el hogar. Hasta ahora, lo que me gusta es que puedo tener varios repositorios. Si llevo mi computadora portátil a la cabina, todavía tengo el control de la versión, a diferencia de cuando ejecuté CVS en casa. La ramificación es tan fácil como hg clone y trabajar en el clon.

Answer 18

Usamos el control de versión distribuida (Plastic SCM) para escenarios tanto de sitios múltiples como desconectados.

1- Multi-sitio: si tiene grupos distantes, a veces no puede confiar en la conexión a Internet, o no es lo suficientemente rápido y ralentiza a los desarrolladores. Luego, tener un servidor independiente que puede sincronizarse (el plástico replica las ramas hacia atrás y hacia adelante) es muy útil y acelera las cosas. Probablemente sea uno de los escenarios más comunes para las empresas, ya que a la mayoría de ellos todavía les preocupan las prácticas de "distribución total" en las que cada desarrollador tiene su propio repositorio replicado.

2- Desconectado (o verdaderamente distribuido si lo prefiere): cada desarrollador tiene su propio repositorio que se replica hacia adelante y hacia atrás con sus pares o la ubicación central. Es muy conveniente ir a la ubicación del cliente o simplemente irse a casa con su computadora portátil, y continuar siendo capaz de cambiar de sucursales, verificar y registrar el código, mirar el historial, ejecutar anotaciones, etc., sin tener que acceder al "central" remoto. servidor. Luego, cada vez que regresa a la oficina, simplemente replica sus cambios (normalmente sucursales) con unos pocos clics.