Intento comprender los beneficios del sistema de control de versiones distribuido (DVCS).

Encontré Subversion Re-education y este artículo de Martin Fowler muy útil.

Mercurial y otros DVCS promueven una nueva forma de trabajar en código con conjuntos de cambios y compromisos locales. Evita fusionar el infierno y otros problemas de colaboración.

Esto no nos afecta, ya que practico la integración continua y trabajar solo en una sucursal privada no es una opción, a menos que estemos experimentando. Usamos una rama para cada versión principal, en la que corregimos errores fusionados del tronco.

Mercurial te permite tener lugartenientes

Entiendo que esto puede ser útil para proyectos muy grandes como Linux, pero no veo el valor en equipos pequeños y altamente colaborativos (de 5 a 7 personas).

Mercurial es más rápido, ocupa menos espacio en el disco y la copia local completa permite registros más rápidos y operaciones diferenciales.

Esto tampoco me preocupa, ya que no noté problemas de velocidad o espacio con SVN incluso con proyectos muy grandes en los que estoy trabajando.

Estoy buscando sus experiencias personales y / u opiniones de antiguos geeks de SVN. Especialmente con respecto al concepto de conjuntos de cambios y al aumento general del rendimiento que midió.

ACTUALIZACIÓN (12 de enero) : ahora estoy convencido de que vale la pena intentarlo.

ACTUALIZACIÓN (12 de junio) : besé a Mercurial y me gustó. El sabor de su cereza se compromete localmente. Besé a Mercurial solo para probarlo. Espero que mi servidor SVN no le importe. Se sintió tan mal. Se sintió tan bien. No quiero decir que esté enamorado esta noche .

ACTUALIZACIÓN FINAL (29 de julio) : Tuve el privilegio de revisar el próximo libro de Eric Sink llamado Version Control by Example . Terminó de convencerme. Iré por Mercurial.

Nota: Consulte "EDITAR" para ver la respuesta a la pregunta actual.

En primer lugar, lea Subversion Re-education de Joel Spolsky. Creo que la mayoría de sus preguntas serán respondidas allí.

Otra recomendación, la charla de Linus Torvalds sobre Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Este otro también puede responder la mayoría de sus preguntas, y es bastante entretenido.

Por cierto, algo que me parece bastante divertido: incluso Brian Fitzpatrick y Ben Collins-Sussman, dos de los creadores originales de subversion dijeron en una charla de Google "lo siento por eso" refiriéndose a que la subversión es inferior al mercurial (y DVCS en general).

Ahora, IMO y, en general, la dinámica del equipo se desarrolla de forma más natural con cualquier DVCS, y un beneficio sobresaliente es que puede comprometerse fuera de línea porque implica lo siguiente:

• No depende de un servidor y una conexión, lo que significa tiempos más rápidos.
• No ser esclavo de los lugares donde puede obtener acceso a Internet (o una VPN) solo para poder comprometerse.
• Todos tienen una copia de seguridad de todo (archivos, historial), no solo del servidor. Lo que significa que cualquiera puede convertirse en el servidor .
• Puede comprometerse compulsivamente si lo necesita sin alterar el código de los demás . Los compromisos son locales. No se pisan los pies mientras se comprometen. No se rompen las compilaciones o entornos de otros simplemente comprometiéndose.
• Las personas sin "acceso de compromiso" pueden comprometerse (porque comprometerse en un DVCS no implica cargar código), reduciendo la barrera para las contribuciones, puede decidir retirar sus cambios o no como integrador.
• Puede reforzar la comunicación natural ya que un DVCS hace que esto sea esencial ... en subversión, lo que tienes en cambio son las carreras de compromiso, que fuerzan la comunicación, pero al obstruir tu trabajo.
• Los contribuyentes pueden asociarse y manejar su propia fusión, lo que significa menos trabajo para los integradores al final.
• Los contribuyentes pueden tener sus propias sucursales sin afectar las de los demás (pero poder compartirlas si es necesario).

Sobre tus puntos:

• La fusión del infierno no existe en DVCSland; no necesita ser manejado Ver siguiente punto .
• En los DVCS, todos representan una "rama", lo que significa que hay fusiones cada vez que se realizan cambios. Las ramas con nombre son otra cosa.
• Puede seguir utilizando la integración continua si lo desea. Sin embargo, no es necesario en mi humilde opinión, ¿por qué agregar complejidad ?, solo mantenga sus pruebas como parte de su cultura / política.
• Mercurial es más rápido en algunas cosas, git es más rápido en otras cosas. No realmente depende de DVCS en general, sino de sus implementaciones particulares AFAIK.
• Todos siempre tendrán el proyecto completo, no solo tú. Lo distribuido tiene que ver con que puede confirmar / actualizar localmente, compartir / tomar desde fuera de su computadora se llama empujar / tirar.
• Nuevamente, lea Subversion Re-education. Los DVCS son más fáciles y más naturales, pero son diferentes, no intente pensar que cvs / svn === es la base de todas las versiones.

Estaba aportando algo de documentación al proyecto de Joomla para ayudar a predicar una migración a DVCS, y aquí hice algunos diagramas para ilustrar centralizado vs distribuido.

Centralizado

Distribuido en práctica general

Distribuido al máximo

Usted ve en el diagrama que todavía hay un "repositorio centralizado", y este es uno de los argumentos favoritos de los fanáticos del versionado centralizado: "todavía está siendo centralizado", y no, no lo es, ya que el repositorio "centralizado" es solo un repositorio que usted todos están de acuerdo (por ejemplo, un repositorio oficial de github), pero esto puede cambiar en cualquier momento que lo necesite.

Ahora, este es el flujo de trabajo típico para proyectos de código abierto (por ejemplo, un proyecto con colaboración masiva) usando DVCS:

Bitbucket.org es algo así como un equivalente de github para mercurial, sepa que tienen repositorios privados ilimitados con espacio ilimitado, si su equipo es más pequeño que cinco, puede usarlo de forma gratuita.

La mejor manera de convencerse de usar un DVCS es probando un DVCS, cada desarrollador de DVCS experimentado que haya usado svn / cvs le dirá que vale la pena y que no saben cómo sobrevivieron todo su tiempo sin él.

EDITAR : Para responder a su segunda edición, solo puedo reiterar que con un DVCS tiene un flujo de trabajo diferente, le aconsejaría que no busque razones para no intentarlo debido a las mejores prácticas , parece que cuando la gente argumenta que OOP no es necesario porque pueden sortear patrones de diseño complejos con lo que siempre hacen con el paradigma XYZ; Puedes beneficiarte de todos modos.

Pruébalo, verás cómo trabajar en "una sucursal privada" es en realidad una mejor opción. Una razón por la que puedo decir por qué lo último es cierto es porque pierdes el miedo a comprometerte , permitiéndote hacerlo en cualquier momento que creas conveniente y trabajar de una manera más natural.

Con respecto a "fusionar el infierno", usted dice "a menos que estemos experimentando", yo digo "incluso si está experimentando + manteniendo + trabajando en v2.0 renovado al mismo tiempo ". Como dije antes, fusionar el infierno no existe porque:

• Cada vez que se compromete genera una rama sin nombre, y cada vez que sus cambios se encuentran con los cambios de otras personas, se produce una fusión natural.
• Debido a que los DVCS recopilan más metadatos para cada confirmación, se producen menos conflictos durante la fusión ... por lo que incluso podría llamarlo una "fusión inteligente".
• Cuando te topas con conflictos de fusión, esto es lo que puedes usar:

Además, el tamaño del proyecto no importa, cuando cambié de subversión ya estaba viendo los beneficios mientras trabajaba solo, todo se sentía bien. Los conjuntos de cambios (no exactamente una revisión, pero un conjunto específico de cambios para archivos específicos que incluye una confirmación, aislada del estado de la base de código) le permiten visualizar exactamente lo que quiso decir al hacer lo que estaba haciendo a un grupo específico de archivos, No todo el código base.

En cuanto a cómo funcionan los conjuntos de cambios y el aumento del rendimiento. Trataré de ilustrarlo con un ejemplo que me gusta dar: el cambio de proyecto mootools de svn ilustrado en su gráfico de red github .

antes de

Después

Lo que está viendo es que los desarrolladores pueden concentrarse en su propio trabajo mientras se comprometen, sin temor a descifrar el código de los demás, se preocupan por descifrar el código de los demás después de presionar / tirar (DVCS: primero confirmar, luego presionar / tirar, luego actualizar ) pero dado que la fusión es más inteligente aquí, a menudo nunca lo hacen ... incluso cuando hay un conflicto de fusión (lo cual es raro), solo pasas 5 minutos o menos reparándolo.

Mi recomendación para usted es buscar a alguien que sepa cómo usar mercurial / git y decirle que se lo explique de manera práctica. Al pasar aproximadamente media hora con algunos amigos en la línea de comando mientras utilizamos mercurial con nuestros escritorios y cuentas de bitbucket que les muestran cómo fusionarse, incluso inventando conflictos para que vean cómo solucionarlos en una cantidad de tiempo ridícula, pude mostrar ellos el verdadero poder de un DVCS.

Finalmente, te recomiendo que uses mercurial + bitbucket en lugar de git + github si trabajas con Windows. Mercurial también es un poco más simple, pero git es más potente para una gestión de repositorio más compleja (por ejemplo, git rebase ).

Algunas lecturas recomendadas adicionales:

• Sistemas de control de revisión distribuida: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: por favor relájate
• Control de versiones distribuidas y Git [Parte 1] y Control de versiones distribuidas y Git [Parte 2]
• Git / Mercurial vs. Subversion: ¡Lucha!
• DVCS vs Subversion smackdown, ronda 3
• Por qué me gusta más Mercurial que Git ( parte 1 , parte 2 )
• Contribuyendo con Git: reduciendo las fricciones de la colaboración de código abierto con Git VCS
• "¿Cómo han funcionado los DVCS hasta ahora?" - Publicar en el Joomla! La lista de correo de Framework Development solicita comentarios después de la adopción experimental de mercurial y git para Joomla! Proyecto de plataforma
• Ramificación de DVCS (con Mercurial) : una introducción detallada y orientada a ejemplos de cómo se ve la ramificación en un DVCS, que es posiblemente la característica más importante en estos sistemas

Lo que está diciendo es, entre otras cosas, que si esencialmente se queda en una sola rama, entonces no necesita control de versión distribuido.

Eso es cierto, pero ¿no es una restricción innecesariamente fuerte a su forma de trabajar, y una que no escala bien a múltiples ubicaciones en múltiples zonas horarias? ¿Dónde debería ubicarse el servidor de subversión central, y todos deberían ir a casa si ese servidor por alguna razón está caído?

Los DVCS son para Subversion, lo que Bittorrent es para ftp

(Técnicamente, no legalmente). Quizás si lo piensas bien, podrías entender por qué es un salto tan grande hacia adelante.

Para mí, nuestro cambio a git, inmediatamente resultó en

• Nuestras copias de seguridad son más fáciles de hacer (solo "actualización remota de git" y ya está)
• Es más fácil realizar pequeños pasos cuando se trabaja sin acceso al repositorio central. Simplemente trabajas y sincronizas cuando vuelves a la red que aloja el repositorio central.
• Construcciones más rápidas de Hudson. Mucho, mucho más rápido usar git pull que actualizar.

Entonces, considere por qué bittorrent es mejor que ftp, y reconsidere su posición :)

Nota: Se ha mencionado que hay casos de uso donde ftp es más rápido y que bittorrent. Esto es cierto de la misma manera que el archivo de respaldo que mantiene su editor favorito es más rápido de usar que un sistema de control de versiones.

La característica principal de los sistemas de control de versiones distribuidas es la parte distribuida. No desprotege una "copia de trabajo" del repositorio, clona una copia completa del repositorio. Esto es enorme, ya que proporciona beneficios poderosos:

• Puede disfrutar de los beneficios del control de versiones, incluso cuando no tiene acceso a Internet como ... Desafortunadamente, este es usado en exceso y sobrevalorado como una razón DVCS es increíble --- simplemente no es un fuerte punto de venta como muchos de nos encontramos codificando sin acceso a internet tan a menudo como comienza a llover ranas.

• La verdadera razón por la que un repositorio local es asesino es que usted tiene control total sobre su historial de confirmación antes de que se envíe al repositorio maestro .

Alguna vez solucionó un error y terminó con algo como:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

Y así. La historia de este tipo es desordenada: en realidad solo había una solución, pero ahora la implementación se extiende entre muchas confirmaciones que contienen artefactos no deseados, como la adición y eliminación de declaraciones de depuración. Con un sistema como SVN, la alternativa es no comprometerse (!!!) hasta que todo esté funcionando para mantener limpio el historial. Incluso entonces, los errores se escapan y la Ley de Murphy está esperando para brutalizarte cuando cantidades importantes de trabajo no están protegidas por el control de versiones.

Tener un clon local del repositorio, que usted posee , corrige esto, ya que puede volver a escribir el historial mediante la implementación continua de los compromisos "arreglarlo" y "oops" en el compromiso "corregir errores". Al final del día, se envía una confirmación limpia al repositorio principal que se ve así:

r321 Fixed annoying bug.

Cuál es la forma en que debería ser.

La capacidad de reescribir el historial es aún más poderosa cuando se combina con el modelo de ramificación. Un desarrollador puede hacer un trabajo completamente aislado dentro de una rama y luego, cuando llega el momento de llevar esa rama al tronco, tiene todo tipo de opciones interesantes:

• Haz una fusión simple de vainilla . Trae todo en verrugas y todo.

• Haz una rebaja . Le permite ordenar el historial de la rama, reorganizar el orden de las confirmaciones, descartar las confirmaciones, unir las confirmaciones, volver a escribir los mensajes de confirmación, ¡incluso editar las confirmaciones o agregar nuevas! Un sistema de control de versiones distribuido tiene un gran soporte para la revisión de código.

Una vez que aprendí cómo los repositorios locales me permitieron editar mi historia en aras de la cordura de mis compañeros programadores y mi futuro yo, colgué SVN para siempre. Mi cliente de Subversion es ahora git svn.

Permitir que los desarrolladores y gerentes ejerzan el control editorial sobre el historial de compromiso da como resultado un mejor historial del proyecto y tener un historial limpio para trabajar realmente ayuda a mi productividad como programador. Si todo esto habla sobre "reescribir el historial" te asusta, no te preocupes ya que para eso están los repositorios centrales, públicos o maestros. La historia puede (¡y debería!) Reescribirse hasta el punto en que alguien la lleve a una rama en un repositorio del que otras personas se están ocupando. En ese punto, la historia debe tratarse como tallada en una tableta de piedra.

La respuesta de dukofgamings es probablemente tan buena como puede ser, pero quiero abordar esto desde una dirección diferente.

Supongamos que lo que usted dice es absolutamente cierto, y que al aplicar buenas prácticas puede evitar los problemas que DVCS fue diseñado para solucionar. ¿Significa esto que un DVCS no le ofrecería ninguna ventaja? La gente apesta en seguir las mejores prácticas. La gente se va a equivocar. Entonces, ¿por qué evitaría el software que está diseñado para solucionar un conjunto de problemas, eligiendo en cambio confiar en las personas para hacer algo que puede predecir de antemano que no van a hacer?

Sí, duele cuando tienes que fusionar grandes commits en subversion. Pero esta también es una gran experiencia de aprendizaje, lo que le permite hacer todo lo posible para evitar la fusión de conflictos. En otras palabras, aprende a registrarse con frecuencia . La integración temprana es algo muy bueno para cualquier proyecto compartido. Mientras todos hagan eso, usar subversión no debería ser un gran problema.

Git, por ejemplo, fue diseñado para el trabajo distribuido y alienta a las personas a trabajar en sus propios proyectos y crear sus propios tenedores para una fusión (eventual) más tarde. Fue no diseñado específicamente para la integración continua en una "pequeña y altamente colaborativas equipos", que es lo que el PO está pidiendo. Es más bien lo contrario, ahora que lo pienso. No tendrá ningún uso para sus elegantes funciones distribuidas si todo lo que está haciendo es sentarse en la misma habitación trabajando juntos en el mismo código.

Entonces, para un equipo de uso compartido de CI, realmente no creo que importe mucho si usa un sistema distribuido o no. Se reduce a una cuestión de gusto y experiencia.

Porque debes desafiar continuamente tu propio conocimiento. Eres aficionado a la subversión, y puedo entenderlo porque lo utilicé durante muchos años y quedé muy contento, pero eso no significa que siga siendo la herramienta que más te convenga.

Creo que cuando comencé a usarlo, era la mejor opción en ese momento. Pero con el tiempo aparecen otras herramientas, y ahora prefiero git, incluso para mis propios proyectos de tiempo libre.

Y la subversión tiene algunas deficiencias. Por ejemplo, si cambia el nombre de un directorio en el disco, entonces no se cambia el nombre en el repositorio. El movimiento de archivos no es compatible, lo que hace que un archivo se mueva una operación de copia / eliminación, lo que dificulta la fusión de los cambios cuando los archivos se han movido / renombrado. Y el seguimiento de fusión no está realmente integrado en el sistema, sino que se implementa en forma de solución alternativa.

Git resuelve estos problemas (incluida la detección automática de si un archivo se ha movido, ni siquiera necesita decir que es un hecho).

Por otro lado, git no le permite ramificarse en niveles de directorio individuales como lo hace la subversión.

Entonces, mi respuesta es que debe investigar alternativas, ver si se ajusta mejor a sus necesidades de lo que está familiarizado y luego decidir.

Con respecto al rendimiento, Git o cualquier otro DVCS tiene una gran ventaja sobre SVN cuando tiene que cambiar de una rama a otra, o pasar de una revisión a otra. Como todo se almacena localmente, las cosas son mucho más rápidas que para SVN.

¡Esto solo podría hacerme cambiar!

En lugar de aferrarse a la idea de que "al aplicar las mejores prácticas no necesita un DVCS", ¿por qué no considerar que el flujo de trabajo SVN es un flujo de trabajo, con un conjunto de mejores prácticas, y el flujo de trabajo GIT / Hg es un flujo de trabajo diferente, con un conjunto diferente de mejores prácticas.

git bisect (y todas sus implicaciones en su repositorio principal)

En Git, un principio muy importante es que puedes encontrar errores usando git bisect. Para hacer esto, toma la última versión que ejecutó que se sabía que funcionaba, y la primera versión que ejecutó que se sabía que fallaba, y realiza (con la ayuda de Git) una búsqueda binaria para descubrir qué confirmación causó el error. Para hacer esto, todo su historial de revisiones debe estar relativamente libre de otros errores que puedan interferir con su búsqueda de errores (lo creas o no, esto realmente funciona bastante bien en la práctica, y los desarrolladores del kernel de Linux hacen esto todo el tiempo).

Para lograr la git bisectcapacidad, desarrolle una nueva característica en su propia rama de características , vuelva a armarla y limpie el historial (para que no tenga ninguna revisión no operativa conocida en su historial, solo un montón de cambios que cada uno lo lleva a la mitad) para solucionar el problema), y luego, cuando la función está lista, la combina en la rama principal con el historial de trabajo.

Además, para que esto funcione, debe tener disciplina sobre la versión de la rama principal desde la que inicia la rama de características. No puede simplemente comenzar desde el estado actual de la masterrama porque eso puede tener errores no relacionados, por lo que el consejo en la comunidad del kernel es comenzar a trabajar desde la última versión estable del kernel (para grandes características) o comenzar a trabajar del último candidato de lanzamiento etiquetado.

Mientras tanto, también puede hacer una copia de seguridad de su progreso intermedio empujando la rama de características a un servidor, y puede empujar la rama de características a un servidor para compartirla con otra persona y obtener comentarios, antes de que la característica esté completa, antes de que tenga que convierta el código en una característica permanente de la base de código con la que todos * en su proyecto tienen que lidiar.

La página de manual de gitworkflows es una buena introducción a los flujos de trabajo para los que Git está diseñado. También Why Git is Better than X analiza los flujos de trabajo de git.

Grandes proyectos distribuidos

¿Por qué necesitamos lugartenientes en un equipo altamente colaborador con buenas prácticas y buenos hábitos de diseño?

Porque en proyectos como Linux, hay tantas personas involucradas que están tan geográficamente distribuidas que es difícil colaborar tanto como un pequeño equipo que comparte una sala de conferencias. (Sospecho que para desarrollar un producto grande como Microsoft Windows que, incluso si todas las personas se encuentran en el mismo edificio, el equipo es demasiado grande para mantener el nivel de colaboración que hace que un VCS centralizado funcione sin lugartenientes).

¿Por qué no usarlos en tándem? En mi proyecto actual nos vemos obligados a usar CVS. Sin embargo, también mantenemos repositorios locales de git para desarrollar funciones. Esto es lo mejor de ambos mundos porque puedes probar varias soluciones y mantener versiones de lo que estás trabajando en tu propia máquina. Esto le permite revertir a versiones anteriores de su función o probar varios enfoques sin tener problemas cuando confunde su código. Tener un repositorio central le brinda los beneficios de tener un repositorio centralizado.

No tengo experiencia personal con DVCS, pero de lo que deduzco de las respuestas aquí y algunos documentos vinculados, la diferencia más fundamental entre DVCS y CVCS es el modelo de trabajo utilizado

DVCS

El modelo de trabajo de DVCS es que está haciendo un desarrollo aislado . Está desarrollando su nueva función / corrección de errores aisladamente de todos los demás cambios hasta el momento en que decida lanzarla al resto del equipo. Hasta ese momento, puede hacer los check-ins que desee, porque a nadie más le molestará.

CVCS

El modelo de trabajo de CVCS (en particular Subversion) es que está haciendo un desarrollo colaborativo . Está desarrollando su nueva función / corrección de errores en colaboración directa con todos los demás miembros del equipo y todos los cambios están disponibles de inmediato para todos.

Otras diferencias

Otras diferencias entre svny git/ hg, como las revisiones frente a los conjuntos de cambios son incidentales. Es muy posible crear un DVCS basado en revisiones (como las tiene Subversion) o un CVCS basado en conjuntos de cambios (como los tienen Git / Mercurial).

No voy a recomendar ninguna herramienta en particular, porque depende principalmente del modelo de trabajo con el que usted (y su equipo) se sientan más cómodos.
Personalmente, no tengo problemas para trabajar con un CVCS.

• No tengo miedo de registrar cosas, ya que no tengo problemas para ponerlo en un estado incompleto pero compilable.
• Cuando experimenté el infierno de fusión, fue en situaciones donde habría ocurrido en ambos svny git/ hg. Por ejemplo, V2 de algún software estaba siendo mantenido por un equipo diferente, usando un VCS diferente, mientras estábamos desarrollando V3. Ocasionalmente, las correcciones de errores tendrían que importarse del V2 VCS ​​al V3 VCS, lo que básicamente significaba hacer un check-in muy grande en el V3 VCS (con todas las correcciones de errores en un solo conjunto de cambios). Sé que no era lo ideal, pero fue una decisión de la gerencia usar diferentes sistemas VCS.