Soy un geek de Subversion, ¿por qué debería considerar o no considerar Mercurial o Git o cualquier otro DVCS?

300

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.

Robin Maben
fuente
8
También estoy muy interesado en esto. Subversion se ajusta a la forma en que me enseñaron a pensar sobre el control de versiones (proveniente de CVS y similares). Sin embargo, aunque he tenido que usar Mercurial y Git para probar algunas correcciones de errores para proyectos de código abierto, todavía no me he convertido.
Berin Loritsch
29
+1 para la pregunta. Hoy en día se ha convertido en un culto a la carga que la distribución es simplemente mejor, más rápida, más simple, más natural y sin problemas y un 90% más brillante en comparación con la centralizada. Excepto que necesariamente no lo es. Son herramientas diferentes , y cada una puede tener ventajas en algunos contextos y desventajas en otros contextos.
Joonas Pulakka
17
@Sharpie: Después de haber usado ambos svn, gity hgdurante años, soy bastante consciente de sus pros y sus contras. Si bien gites sin duda el más poderoso de estos, es importante reconocer que más poderoso no implica automáticamente mejor . Emacs es ciertamente más poderoso que cualquier editor de texto javascript que se ejecute en un navegador web, pero, curiosamente, ¡estoy escribiendo este comentario en un editor de texto del navegador javascript ahora mismo! La simplicidad , incluso la estupidez, tiene valor en muchos contextos. El uso centralizado svny algo git-svnlocal ofrece lo mejor de ambos mundos.
Joonas Pulakka
99
@Sharpie: Es bueno para ti que te guste. Pero el profesional de un hombre es la estafa de otro hombre. Algunas personas consideran que la claridad de un único repositorio centralizado con un solo tronco canónico es increíblemente valioso. Aquí hay una presentación sobre cómo Google mantiene el código fuente de todos sus proyectos, más de 2000, en un solo tronco de código que contiene cientos de millones de líneas de código, con más de 5000 desarrolladores accediendo al mismo repositorio. ¿Prefieres preferir 5000 servidores y la historia de 2000 proyectos en el escritorio de todos? -)
Joonas Pulakka
21
-1 para la referencia de Katy Perry. ;)
Amadiere

Respuestas:

331

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

texto alternativo

Distribuido en práctica general

texto alternativo

Distribuido al máximo

texto alternativo

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:

texto alternativo

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:

texto alternativo

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

texto alternativo

Después

texto alternativo

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:

dukeofgaming
fuente
18
Gran respuesta, pero solo una pregunta para aquellos de nosotros en el mismo barco que OP: ¿puede explicar cómo no existe la fusión del infierno? ¿Un integrador o un contribuyente no necesitan pasar por las mismas acciones cuando su bifurcación ha quedado desactualizada?
Nicole
17
Buena respuesta. Solo una nota al margen: aunque Spolsky puede tener algunos puntos interesantes, tenga en cuenta que también está tratando de vender un producto utilizando esos puntos como material de venta, lo que los hace un poco sesgados.
Martin Wickman el
55
Leí esa página de reeducación y no la encontré relevante por muchas razones. Editaré mi pregunta con mi opinión personal sobre el tema.
15
También vale la pena señalar que Git puede actuar como un cliente Subversion, lo que significa que no necesita convertir a todos a Git a la vez; Algunos miembros del equipo pueden usar Git si lo desean, y su flujo de trabajo individual mejora (especialmente porque la fusión es mucho más fácil).
greyfade
66
@Pierre, los DVCS se encargan de fusionar los cambios de software de los programadores individuales, pero no de hacer que el software compile o pase las pruebas unitarias existentes. Todavía es necesario otro software para hacer esto cada vez que el cambio de la fuente, y la mejor apuesta que tenemos en estos días está utilizando un IC-motor (y hacerlo correctamente)
59

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.


fuente
Casi estoy decidido a probarlo con un proyecto real.
Buena idea. Recuerda entrar con la mentalidad de "¡Realmente ME GUSTA esto!" en lugar de "¡No quiero HACER esto!". Hay mucho que aprender. Si elige git, github tiene mucha buena ayuda en línea. Si elige hg, Joel ha escrito un buen material en línea. Si elige bzr, Canonical probablemente tenga mucho material en línea bueno. ¿Otros?
3
Hmm, eso supone que crees que Bittorrent es mejor que FTP ...
Murph
2
@Murph, sí, y también Blizzard (¿en quién creo que podemos estar de acuerdo sabe cómo lidiar con la sincronización masiva en línea?). wowwiki.com/Blizzard_Downloader
2
@Murph, inicia un servidor torrent en el servidor y un cliente torrent en el cliente. No dificil. Debería comprarle de inmediato que solo los archivos que han cambiado deben actualizarse. También, ¿ha considerado qué rsync en lugar de ftp podría comprarle para actualizaciones incrementales?
46

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.

marcador, rotulador
fuente
66
Reescribiendo la historia: ¿eso es solo una cosa de Git? ¿O también es fácil en Mercurial? (Si es así, realmente necesito comenzar a hacerlo.)
Paul D. Waite
3
Al hacer esto, se debe tener en cuenta la disciplina del kernel de Linux, es decir, nunca volver a redactar (o reescribir el historial) una rama que haya publicado públicamente. Si tiene sucursales que son públicas para uso a corto plazo (para fusionarse en sucursales que se desechan con frecuencia, como linux-next, o para que alguien las revise y luego deseche sus copias locales), entonces puede cambiar las ramas, pero su otros usuarios deben tener claro que la convención para esa rama es que puede ser modificada y no debe fusionarse en las ramas a largo plazo de otras personas.
Ken Bloom
44
Es muy posible que tenga acceso a Internet sin tener acceso completo a la red interna. Eso me pasa con frecuencia cuando viajo.
55
No requerir acceso a Internet es un gran problema, porque de ahí proviene la velocidad de DVCS. Tan pronto como tenga que enviar paquetes a través de una red, está ralentizando el proceso en un orden de magnitud, independientemente de cuán buena sea su conexión.
Adam Lassek
66
@Paul, entiendo que en Mercurial se puede hacer, pero no es la funcionalidad básica o la filosofía.
Benjol
18

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?

filosodad
fuente
2
En realidad, propondría este argumento en contra de DCVS. Mi compañía recientemente cambió a Mercurial de CVS. Las personas están borrando los cambios de otras personas durante las fusiones con mucha más frecuencia cuando están en CVS.
Juozas Kontvainis
@JuozasKontvainis: No conozco muy bien el mercurial, pero en git puedes rechazar los empujes que incluyen fusiones que no tienen HEAD como padre, lo que evita que los usuarios empujen cambios que no tienen los cambios más recientes del maestro incluido. Estoy seguro de que hay algo similar en mercurial.
naught101 01 de
@ naught101: en realidad, mi empresa tiene esa configuración habilitada. Lo que sucede es que el programador confirma sus cambios localmente, luego intenta presionar. Obtiene una respuesta del servidor que necesita fusionarse antes de poder presionar. Obtiene actualizaciones del servidor e intenta realizar una confirmación de fusión. En este punto, no sé exactamente cómo esas personas hicieron un compromiso de fusión, pero en varias ocasiones ese compromiso de fusión básicamente borró los cambios que obtuvieron del servidor.
Juozas Kontvainis
1
Parece que la gente sacó los cambios y luego eliminó los cambios que obtuvieron del servidor cuando se fusionaron (lo cual es posible). Por supuesto, el conjunto de cambios del servidor todavía está allí, por lo que puede restablecer el repositorio al estado en que estaba antes de sus cambios.
philosodad
1
en realidad, suena así: randyfay.com/content/avoiding-git-disasters-gory-story buen artículo no crítico sobre qué puede salir mal con un repositorio de git si no sabes lo que estás haciendo.
gbjbaanb
9

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.

Martin Wickman
fuente
2
Git fue diseñado para el trabajo distribuido en todo el mundo y alienta a las personas a trabajar en sus propios proyectos y crear sus propios tenedores. Fue no diseñado específicamente para la integración continua en "pequeños y de gran colaboración equipos", que es lo que el PO está pidiendo.
Martin Wickman el
44
Adivina qué, obtienes conflictos más pequeños / más fáciles de resolver. Pero si dos personas están cambiando las mismas partes del código, tiene un problema de planificación en su equipo y ningún VCS puede resolverlo. Distribuido o no.
Martin Wickman el
44
El OP está en un equipo compartido con CI. Esto significa que a menudo realizan muchos registros pequeños (varias veces al día). Dado esto, no veo ninguna razón por la que el uso de un dvcs debería dar una ventaja particular y no veo ninguna razón por la que se produzcan grandes fusiones y, por lo tanto, no se fusionen. Sin embargo, no recomendaría svn para un equipo distribuido, pero ese no es el caso aquí.
Martin Wickman el
2
@MartinWickman - Mercurial fue diseñado para comprometerse, ramificarse y fusionarse de manera rápida y económica. Eso suena perfecto para una integración continua. Personalmente, creo que tener la capacidad de Alice de bifurcar sus cambios y sugerir que Bob los tire y fusione sus cambios en esa bifurcación para verificar si hay problemas, todo sin tocar el servidor central o presionar los cambios en cualquier lugar, parece una gran manera para equipos pequeños y altamente colaborativos para trabajar.
philosodad
2
Mis $ 0.02. He usado Subversion, Mercurial y Git ahora para varios proyectos. Subversion realmente parece ser la mejor opción para un grupo muy integrado que realiza una integración continua. Mercurial es más adecuado para grupos que solo pueden hacer una compilación por día con muchos más cambios de código cada vez (eso crearía problemas de fusión en SVN). Git parece ser el camino a seguir para las personas que tienen equipos que pueden pasar días / semanas sin realmente juntar el código para hacer una compilación.
Brian Knoblauch
8

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.

Pete
fuente
Muy cierto, las alternativas experimentales deberían ser automáticas.
git usa cierta heurística para determinar si un archivo se ha movido, es bueno pero no perfecto.
gbjbaanb
De acuerdo con eso, incluso si odias la nueva herramienta que usan los malditos niños, creo que es importante forzarte a al menos probar cosas nuevas, especialmente si estas cosas están haciendo olas masivas.
Tjaart
7

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!

Xavier Nodet
fuente
De acuerdo, git checkout es extremadamente rápido.
1 por señalarlo, saltando entre las ramas / conjuntos de cambios es bastante rápido
dukeofgaming
3

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

Ken Bloom
fuente
No entiendo tu primer punto. ¿Tienes algunas referencias? Con respecto al último, dividiría el proyecto en componentes separados. Nunca trabajé en un proyecto tan grande, el número máximo de desarrolladores que obtuve en el mismo proyecto es de dos docenas.
@Pierre. Eso es ciertamente razonable dividir el proyecto en componentes separados. Dado que Linux es un núcleo monolítico, eso significa (esencialmente) que todos los controladores de dispositivos deben desarrollarse en el mismo repositorio, aunque cada uno es esencialmente un proyecto separado. Al mismo tiempo, quieren la agilidad de sus arquitectos más experimentados para realizar cambios de gran alcance que toquen todos estos controladores, por lo que dividirlos en diferentes repositorios será una molestia. Entonces git (y los lugartenientes) les convienen bien para manejar estas diferentes preocupaciones.
Ken Bloom
También podría estar interesado en leer lo que Martin Fowler tiene que decir sobre SVN versus los flujos de trabajo de Git y Mercurial. martinfowler.com/bliki/VersionControlTools.html
Ken Bloom
2
Hago bisecciones en SVN regularmente para encontrar errores. La única diferencia con Git es que no todo es automático. Pero esto por sí solo no sería suficiente para que cambiemos.
Xavier Nodet
1
La relevancia de git bisect para equipos pequeños es casi nula. Lo obtengo para el núcleo donde se fusionan cientos de cambios de diferentes personas a la vez y se rompen las cosas, pero cuando tienes un equipo de 5, generalmente puedes eliminar todos menos 2-3 parches potenciales culpables con un vistazo rápido al Iniciar sesión.
blucz
2

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

Vadim
fuente
. Sin embargo, sólo se puede establecer un repositorio central con un DVCS (y se puede controlar los permisos tan fuerte como con un CVC ¿Cuáles son los beneficios?
naught101
Es cierto, pero los repositorios centrales de git pueden ser difíciles de configurar si se encuentra en un entorno Windows. Supongo que es prácticamente la única en la que puedo pensar. Nos vimos obligados a usar CVS a nivel corporativo, por lo que realmente no teníamos muchas opciones.
Vadim
1

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.
Bart van Ingen Schenau
fuente
No creo que el desarrollo aislado sea en realidad el modelo de trabajo de DVCS. Una característica importante de un DVCS es que otros miembros del equipo pueden extraer sus cambios locales o clonar su repositorio local. Usted se compromete cuando lo desea, sus cambios siempre están disponibles y sus errores no pueden causar estragos masivos.
philosodad
@philosodad: si otros extraen el código de mi repositorio sin conocer el estado de ese código, aún puede causar estragos. La única diferencia es de quién es la responsabilidad. Y mi código no siempre está disponible. Eso todavía depende de si mis sistemas están configurados para acceso externo.
Bart van Ingen Schenau
Si las personas extraen el código de su repositorio y lo fusionan con el suyo, pueden retroceder, independientemente, sin problemas masivos . En segundo lugar, seguro, si decide rechazar el acceso a su base de código y paralizar una característica importante del sistema, puede forzar el aislamiento en usted mismo. Eso es muy diferente de un sistema modelado para desarrollo aislado. DVCS no lo es. Su comprensión del modelo de trabajo de DVCS es simplemente incorrecta.
philosodad
1
@philosodad: Creo que estoy empezando a entenderlo mejor y mejor: todos pueden tener su desorden, igual que en un CVCS, pero ya no es su culpa, porque no lo presionó. :-)
Bart van Ingen Schenau
Especie de. Pero, por lo general, Alice clonaría o ramificaría primero y luego fusionaría sus cambios, lo que hace que sea más fácil fingir que nunca vio su código de error en primer lugar.
philosodad