version control - usados - ¿Utiliza el control de versión distribuida?

sistemas de control de versiones mas usados (18)

Actualmente, mi empresa utiliza Subversion, CVS, Mercurial y git.

Cuando comenzamos hace cinco años, elegimos CVS, y todavía lo utilizamos 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 sucursales de CVS (y particularmente fusionarlas) y estamos comenzando a utilizar 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 (elaborados en casa) pueden supervisar 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 necesita volver a conectar los cerebros de sus desarrolladores y gerentes para que se alejen del modelo de rama lineal única. La mejor medicina para esto es una dosis de Linus Torvalds diciéndote que eres estúpido y feo si usas 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 bastante esfuerzo, importar nuestra historia de CVS principal en 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 potencialmente se pueden verificar grandes binarios (por ejemplo, versiones de proveedores) sin hacer que todos los repositorios distribuidos sean enormes.

Usamos 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.

Me gustaría saber de las personas que usan 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.

Me interesaría especialmente cualquier persona que lo haya utilizado con compañeros de trabajo en otros países, donde sus máquinas pueden no estar encendidas al mismo tiempo y su conexión es muy lenta.

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

Introducción al control de versiones distribuidas

Entrada de Wikipedia

Usando Subversion

Subversion no se distribuye, así que me hace pensar que necesito un enlace de wikipedia en caso de que las personas no estén seguras de lo que estoy hablando :)

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: flexibilidad del entorno de trabajo y fusión.

No tengo que estar en nuestra VPN, o incluso tener conectividad de red, para tener acceso a capacidades completas de control de versiones. 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.

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

Realmente amo a 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.

Soy un gran defensor del control de fuente centralizado por muchas razones, pero probé 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 interferir con 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.

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

Yo 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.

Intenté con 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 mi código con personas:

Comparto un servidor con un compañero de trabajo y mantenemos un repositorio principal para nuestro proyecto.
Para algunos proyectos OSS en los que trabajo, creamos parches de nuestro trabajo con Mercurial (hg export) y el mantenimiento del proyecto solo los aplicamos en el repositorio (hg import)

Muy fácil de trabajar, pero muy poderoso. Pero, en general, elegir un VSC realmente depende de las necesidades de nuestro proyecto ...

Antes de que apagáramos 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 completamente por separado de cualquier otro cambio (es decir, ramas) creado implícitamente por otros desarrolladores.

Personalmente, creo que el modelo distribuido implementado por TeamWare o el tipo de 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 en el nivel de 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.

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 sucursales locales y trabajar en ellas sin alterar 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 tenían 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.

He usado el bazar por un tiempo y me encanta. Las ramificaciones triviales y la fusión de nuevo dan una gran confianza en el uso de las 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 admite bastantes flujos de trabajo diferentes desde solo, a través del trabajo como un repositorio centralizado para una distribución completa. 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.

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

Mi grupo en el trabajo está usando Git, y ha sido toda la diferencia en el mundo. Estábamos usando 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 facilita mucho estas cosas, y solo se necesita un mínimo de scripts. 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 una gran ventaja, ya que podemos personalizar su comportamiento a través de enganches o scripts que sí lo hacen . git-sh-setup . git-sh-setup , y no parece una pila de kludges como antes.

También a veces 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 lidiar con eso sin problemas (bundles, el mecanismo de clonación básico, formateado parches, etc.).

Algo de esto nos acaba de dejar a principios de los 80 y de adoptar 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.

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

Estoy jugando con Mercurial para mis proyectos hogareños. Hasta ahora, lo que me gusta es que puedo tener múltiples 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 la hg clone y el clon.

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

Control de versión local. A veces estoy trabajando en algo, y quiero mantener un historial de versiones sobre él, 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.
Menos conflictos de fusión. Todavía suceden, pero parecen ser menos frecuentes, y son menos riesgosas, porque todo el código está registrado en mi repositorio local, por lo que incluso si fallo la fusión, siempre puedo hacer una copia de seguridad y volver a hacerlo.
Separa los repos como ramas. Si tengo un par de vectores de desarrollo funcionando 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.
Velocidad. Mercurial es mucho más rápido para trabajar, sobre todo porque la mayoría de las operaciones comunes son locales.

Por supuesto, como 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.

Uso 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 dijiste en qué sistema operativo desarrollaste, pero Git tiene la desventaja de que tienes que 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.

Utilizamos el control de versión distribuida ( Plastic SCM ) para escenarios multi-sitio y 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 de un lado a otro con sus compañeros 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.

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 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 historia --- no se puede recuperar ''el estado de 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. Lo tuve bloqueado con un uso de CPU del 100% durante 9 días tratando de obtener cambios de 3 meses. Tuve una mala experiencia el verano pasado cuando perdí dos semanas tratando de hacer que Darcs funcionara y eventualmente 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.

No uso el control de fuente distribuida, pero tal vez estas preguntas y respuestas relacionadas le brinden algunas ideas: