¿Qué hace SVN mejor que Git? [cerrado]

No hay duda de que la mayoría de los debates sobre las herramientas de programación destilan a la elección personal (por parte del usuario) o al énfasis en el diseño , es decir , optimizar el diseño de acuerdo con los casos de uso particulares (por parte del creador de herramientas). Los editores de texto son probablemente el ejemplo más destacado: un codificador que trabaja en Windows en el trabajo y codifica en Haskell en la Mac en casa, valora la integración multiplataforma y compilador y elige Emacs en lugar de TextMate , etc.

Es menos común que una tecnología recientemente introducida sea genuina, demostrablemente superior a las opciones existentes.

¿Es este el caso de los sistemas de control de versiones (VCS), en particular, VCS centralizado ( CVS y SVN ) versus VCS distribuido ( Git y Mercurial )?

Usé SVN durante unos cinco años, y SVN se usa actualmente donde trabajo. Hace poco menos de tres años, cambié a Git (y GitHub) para todos mis proyectos personales.

Puedo pensar en una serie de ventajas de Git sobre Subversion (y que en su mayor parte resumen las ventajas de distribuir sobre VCS centralizado), pero no puedo pensar en un contraejemplo: alguna tarea (que es relevante y surge en un programador habitual flujo de trabajo) que Subversion funciona mejor que Git.

La única conclusión que he sacado de esto es que no tengo ningún dato, no es que Git sea mejor, etc.

Supongo que existen tales contraejemplos, de ahí esta pregunta.

Subversion es un repositorio central

Si bien muchas personas querrán tener repositorios distribuidos para los beneficios obvios de la velocidad y las copias múltiples, hay situaciones en las que un repositorio central es más deseable. Por ejemplo, si tienes algún código crítico al que no quieres que acceda nadie, probablemente no quieras ponerlo bajo Git. Muchas corporaciones quieren mantener su código centralizado, y (supongo) que todos los proyectos gubernamentales (serios) están bajo repositorios centrales.

La subversión es la sabiduría convencional.

Esto quiere decir que muchas personas (especialmente gerentes y jefes) tienen la forma habitual de numerar las versiones y ver el desarrollo como una "línea única" a lo largo del tiempo codificada en su cerebro. Sin ofender, pero la liberalidad de Git no es fácil de tragar. El primer capítulo de cualquier libro de Git te dice que borres todos los ideales convencionales de tu mente y comiences de nuevo.

Subversion lo hace de una manera, y nada más

SVN es un sistema de control de versiones. Tiene una forma de hacer su trabajo y todos lo hacen de la misma manera. Período. Esto facilita la transición a / desde SVN desde / a otro VCS centralizado. Git NO es ni siquiera un VCS puro: es un sistema de archivos, tiene muchas topologías sobre cómo configurar repositorios en diferentes situaciones, y no hay ningún estándar. Eso hace que sea más difícil elegir uno.

Otras ventajas son:

• SVN admite directorios vacíos
• SVN tiene mejor soporte de Windows
• SVN puede verificar / clonar un subárbol
• SVN admite un control de acceso exclusivo svn lockque es útil para archivos difíciles de combinar.
• SVN admite archivos binarios y archivos grandes con mayor facilidad (y no requiere copiar versiones antiguas en todas partes).
• Agregar un commit implica una cantidad considerablemente menor de pasos ya que no hay ningún pull / push y sus cambios locales siempre se basan implícitamente svn update.

Uno de los beneficios de Subversion sobre Git puede ser que Subversion solo permite ver subárboles. Con Git, todo el repositorio es una unidad, solo puede obtener todo o nada. Con el código modular, esto puede ser bastante bueno en comparación con los submódulos de Git. (Si bien los submódulos de Git también tienen su lugar, obviamente).

Y un pequeño beneficio: Subversion puede rastrear directorios vacíos. Git rastrea el contenido del archivo, por lo que no aparecerá un directorio sin ningún archivo.

Se me ocurren tres. Primero, es un poco más fácil de asimilar, especialmente para los que no son desarrolladores. Conceptualmente es mucho más simple que las opciones DCVS . El segundo es la madurez, especialmente TortoiseSVN en Windows. Sin embargo, TortoiseHg se está poniendo al día rápidamente. En tercer lugar, la naturaleza de la bestia, solo una imagen de un sistema de archivos donde puede ver cosas desde cualquier nivel del árbol, puede ser muy útil en algunos escenarios, como el versionado de una variedad de archivos de configuración muy diferentes en docenas de servidores sin docenas de repositorios.

Esto no quiere decir que no estamos trasladando todo el desarrollo a Mercurial.

• Los repositorios SVN son más manejables desde el punto de vista del administrador y del administrador ( ACL + métodos de autenticación + hotcopy + mirrors + dumps)
• Los ganchos SVN * son más fáciles de implementar y soportar
• svn:external tiene más potencia y flexibilidad que los submódulos
• Los árboles de repositorio basados ​​en el sistema de archivos son más fáciles de usar que los repositorios monolíticos con separación solo lógica.
• SVN tiene más herramientas de cliente diferentes
• SVN tiene interfaces web utilizables por terceros, mucho mejores que las de Git
• SVN no te rompe el cerebro

Escribí esto como un comentario sobre la respuesta de otra persona, pero supongo que merece ser una respuesta en sí misma.

La configuración cuidadosamente elegida de mi empresa para SVN requiere el bloqueo de nivel de archivo para editar contenido, y nunca utiliza la combinación. Como resultado, múltiples desarrolladores compiten por bloqueos, y puede ser un gran cuello de botella, y nunca existe la posibilidad de un conflicto de fusión.

SVN definitivamente hace un control administrativo de arriba hacia abajo mejor que Git. En mi migración de Skunkworks a Git (pidiendo perdón en lugar de permiso) muchas veces aterroricé a mi gerente con la idea de que no hay ningún servidor de control maestro central forzado por software en el que todos somos esclavos.

Mis razones:

• madurez: tanto el servidor como las herramientas (por ejemplo, TortoiseSVN)
• simplicidad: menos pasos involucrados, un commit es un commit. DVCS como Git y Mercurial implican commit, luego push.
• manejo binario: SVN maneja ejecutables binarios e imágenes mejor que Git / Hg. Especialmente útil con proyectos .NET ya que me gusta verificar las herramientas relacionadas con la compilación en el control de código fuente.
• numeración: SVN tiene un esquema de numeración de confirmación legible, que usa solo dígitos, más fácil de rastrear números de revisión. Git y Hg hacen esto de manera muy diferente.

Le agradezco que esté buscando buena información, pero este tipo de pregunta simplemente invita, "¡Creo que Git es mucho ganador, y svn teh suxorz!" respuestas

Lo intenté y personalmente encontré a Git demasiado para mi pequeño equipo. Parecía que sería genial para un gran equipo distribuido o un grupo de equipos que están dispersos geográficamente. Entiendo mucho los beneficios de Git, pero el control de fuente en mi opinión no es algo que me mantenga despierto por la noche.

Soy un cazador de ciervos, y cuando mis amigos y yo salimos están armados hasta los dientes, erizados de munición y equipo de alta tecnología. Me presento con un solo rifle, siete balas y un cuchillo. Si necesito más de siete rondas, entonces estoy haciendo algo mal, y lo hago tan bien como cualquier otra persona.

El punto que estoy tratando de hacer es que si eres un equipo pequeño que trabaja en un proyecto de mediano a pequeño y ya estás familiarizado con SVN, entonces úsalo. Sin duda, es mejor que CVS o (estremecimiento) SourceSafe , y no me lleva más de cinco minutos configurar un repositorio. Git a veces puede ser excesivo.

Todo esto es relativo, y como dijo maple_shaft, si uno funciona para usted, ¡no cambie!

Pero si realmente quieres algo , diría que quizás sea mejor para diseñadores, programadores web y demás : maneja las imágenes y los archivos binarios un poco mejor.

Usabilidad. No es realmente el mérito de Subversion sino más bien TortoiseSVN .. TortoiseGit existe, pero todavía tiene un largo camino por recorrer para igualar TortoiseSVN.

Si preguntaras qué hace Git mejor que SVN, respondería GitHub . Es curioso cómo las herramientas de terceros marcan una gran diferencia.

Cuando no necesita bifurcar y fusionar , SVN (con TortoiseSVN en Windows) es muy fácil de entender y usar. Git es demasiado complejo para los casos simples, ya que trata de facilitar la ramificación / fusión.

(Muchos proyectos pequeños nunca tienen que ramificarse si se gestionan bien. Git está dirigido a los casos complejos; por lo tanto, la mayoría de la documentación de Git supone que debe realizar operaciones complejas como ramificar y fusionar).

Bueno, mi abuelo podría usar SVN en su computadora con Windows XP, pero tendría problemas para usar Git. Tal vez esto sea más un logro de TortoiseSVN sobre TortoiseGit , pero creo que está bastante relacionado con el hecho de que Git es inherentemente más poderoso y, por lo tanto, más complejo, y sería inútil reducirlo al mismo nivel.

Ahora realmente no importa para mi abuelo, porque últimamente no ha hecho ninguna programación. Sin embargo, una vez estuve en un equipo, donde nuestros artistas gráficos también usaban nuestro control de fuente.

Y esas son personas que simplemente esperan que sus herramientas funcionen (yo también, pero tengo una oportunidad realista de hacer que funcionen en caso de falla) y sean intuitivas. Aparte del hecho de que hubiera sido un gran esfuerzo lograr que se llevaran bien con un DVCS , había poco que ganar. Y con solo dos programadores en el equipo, tenía sentido para nosotros también seguir con SVN.

En el trabajo no podía cambiar los desarrolladores de SVN a ningún DVCS por dos razones:

• Pagos parciales (como solo tres carpetas de diferentes profundidades en el árbol del proyecto)
• Bloqueo de archivos (informes en formato binario)

• Sentido de seguridad al hacer un 'svn commit'. Dado que las confirmaciones van al servidor, no hay ningún posible error que pueda hacer que borre mis cambios después de que se confirmen. En git, los commits son locales, así que hasta que presiono, un 'rm -rf' perdido y todo ha terminado.
• Los commits se autentican. Por defecto en git, puedo decir que me estoy comprometiendo como cualquiera.
• Menos comandos para aprender para el uso diario. 'svn checkout', 'svn up' y 'svn commit' te llevarán bastante lejos.
• Los pagos compartidos funcionan mucho mejor. Cuando va a comprometerse, le pide su nombre de usuario / contraseña, no tiene que recordar pasar ciertos argumentos de línea de comando. A veces, en el trabajo, tenemos una máquina compartida con un pago compartido de algún proyecto. Alguien podría decir "Bob, ¿puedes ver esto en esta máquina?", Y él puede, y puede confirmar sus cambios como su usuario sin ningún problema.
• Diseño de repositorio. Puede tener un proyecto general y subproyectos y elegir qué revisar cuando.
• Los números de revisión son enteros incrementales.
• Diseñado para el flujo de trabajo del repositorio central.

Otras personas han publicado algunas respuestas bastante buenas, pero ¿qué pasa con los permisos? Usando Subversion sobre SSH, puede crear una cuenta separada en su servidor para SVN. A los diferentes desarrolladores se les puede dar acceso diferente a diferentes partes del repositorio. ¿Puede GIT hacer eso? Supongo que hay gitolita, pero simplemente no me parece tan flexible o robusta, ni conozco a nadie que realmente la esté usando.

Velocidad. A veces toma 10 o 15 minutos para clonar un gran repositorio de git, mientras que un repositorio de subversión de tamaño similar toma un par de minutos para verificar.

Publico esto como una respuesta en lugar de un comentario.

Admito que DVCS está bastante de moda en este momento, pero intentaré decir por qué.

Los DVCS son mejores porque, como muchas personas han estado diciendo, "esta es la forma en que deberíamos haber estado trabajando desde el principio". Es cierto, puede hacer con un DVCS lo que solía hacer con SVN, por lo que SVN queda obsoleto.

Sin embargo, no todos los proyectos de software son tan buenos como son:

• Los proyectos a largo plazo se han beneficiado mucho de DVCS, ya que utiliza menos gastos generales, permite una gestión mucho mejor (ramificación, etc.) y es muy compatible con hosts como google code y github.

• Esos proyectos no son los únicos, hay otro tipo de proyectos que se están desarrollando en empresas sin ninguna ayuda del mundo exterior o de Internet: todo se hace internamente y, a menudo, a corto plazo. Un buen ejemplo: un videojuego. El código evoluciona rápidamente.

Para el último caso, los desarrolladores realmente no necesitan ramificaciones o funciones sofisticadas que DVCS puede ofrecer, solo quieren compartir el código fuente y los activos. El código que hacen no es probable que se reutilice, porque hay una fecha límite. Confían en SVN en lugar de un DVCS debido a varias razones:

• Los desarrolladores tienen máquinas que pertenecen a la empresa, y esto podría cambiar rápidamente. Configurar un repositorio es una pérdida de tiempo.
• Si esos tipos no tienen su propia máquina, es menos probable que trabajen en el mismo código fuente / parte del proyecto. Más uno para los datos centralizados.
• Las velocidades de red y mucho dinero permiten el uso de un servidor centralizado que se ocupa de todo SVN, es una mala práctica, pero se realizan copias de seguridad, etc.
• SVN es más simple de usar, incluso si es de la manera incorrecta: sincronizar archivos en pares sin redundancia no es un problema simple, y "hacerlo de la manera correcta" simplemente no puede llegar a tiempo si siempre quiere que sea perfecto.

Piensa en la máquina de la industria del juego y en cómo SVN ahorra tiempo; la gente se comunica mucho más sobre esos proyectos porque los juegos son sobre programación repetitiva y código adaptativo: no hay nada difícil de codificar, pero debe hacerse de la manera correcta, CUANTO ANTES. Los programadores son contratados, codifican su parte, lo compilan, lo prueban un poco, se comprometen, listo, los probadores del juego se encargarán del resto.

Los DVCS están hechos para internet y para proyectos muy complejos. SVN son para proyectos de equipo pequeño, a corto plazo y ajustado. No necesita aprender mucho de SVN, es casi un FTP con una diferencia tonta.

Subversion y Git fomentan enfoques particulares (y muy diferentes) para el desarrollo y la colaboración. Algunas organizaciones obtendrán más de Git y otras obtendrán más de Subversion, dependiendo de su organización y cultura.

Git y Mercurial son excelentes para equipos distribuidos y organizados libremente de programadores profesionales altamente competentes. Ambas herramientas DVCS populares fomentan repositorios pequeños, y la reutilización entre desarrolladores se realiza a través de bibliotecas publicadas con interfaces (relativamente) estables.

Subversion, por otro lado, fomenta una estructura de gestión más centralizada y estrechamente acoplada, con más comunicación entre los desarrolladores y un mayor grado de control organizacional sobre las actividades de desarrollo cotidianas. Dentro de estos equipos organizados de manera más compacta, la reutilización entre desarrolladores tiende a realizarse a través de bibliotecas no publicadas con interfaces (relativamente) inestables. TortoiseSVN también permite que Subversion brinde soporte a equipos multidisciplinarios con miembros que no son programadores profesionales (por ejemplo, ingenieros de sistemas, ingenieros de algoritmos u otros especialistas en el área temática).

Si su equipo está distribuido, con miembros que trabajan desde casa o desde muchos sitios internacionales diferentes, o si prefieren trabajar solos y en silencio, con poca comunicación cara a cara, entonces un DVCS como Git o Mercurial será una buena opción. ajuste cultural.

Si, por otro lado, su equipo está ubicado en un solo sitio, con un enfoque de "equipo" activo para el desarrollo y mucha comunicación cara a cara, con un "zumbido" en el aire, entonces SVN puede ser un mejor ajuste cultural, especialmente si tienes muchos equipos interdisciplinarios.

Por supuesto, es posible configurar Git y Hg (potentes y flexibles como son) para que hagan casi lo que quieran, pero definitivamente es más trabajo y definitivamente son más difíciles de usar, particularmente para aquellos miembros del equipo que naturalmente, no estaría inclinado a utilizar ningún tipo de control de versiones.

Finalmente, también encuentro que compartir la funcionalidad usando el desarrollo de bibliotecas "en caliente" bajo Svn (con CI y un enfoque basado en pruebas) permite un ritmo de desarrollo coordinado que es difícil de lograr con un equipo más distribuido y poco acoplado.

A continuación se presentan las dos razones por las que todavía me quedo con SVN.

1. La curva de aprendizaje. SVN es más fácil que Git, incluso la configuración (servidor o cliente también), usabilidad y comandos.
2. Mejores paquetes de servidor como Subversion Edge , VisualSVN , uberSVN , etc.

Hay dos tendencias principales en el control de versiones en este momento; Distribución e Integración .

Git es genial en la descentralización.

SVN tiene muchas herramientas integradas que se integran con él. Es común configurar su servidor SVN para que cuando registre una solución, mencione el número de error en el comentario de registro, y lo configura automáticamente pero en un estado "en prueba", y alerta al probador asignado que necesitan Míralo. Luego puede etiquetar una versión y obtener una lista de todos los errores corregidos en esta versión.

Las herramientas que hacen esto con SVN son maduras y se usan todos los días.

En Subversion, puede editar los mensajes de registro (también llamados "mensajes de confirmación") después de que se realiza la confirmación y se empuja. Para la mayoría de los usos prácticos, esto es imposible por diseño en sistemas descentralizados, incluido git. Por supuesto, en git puedes hacer "git commit --amend", pero eso no te ayuda después de que tu commit haya sido enviado a otra parte. En SVN, cuando edita el mensaje de registro, lo está haciendo en el repositorio central que todos comparten, por lo que todos obtendrán la edición y sin que cambie el identificador de la revisión.

Editar mensajes de registro después del hecho suele ser muy útil. Además de corregir un error u omisión en un mensaje de registro, le permite hacer cosas como actualizar un mensaje de registro para referirse a una confirmación futura (como una revisión que corrige un error o completa el trabajo introducido en la revisión actual) .

Por cierto, no hay peligro de perder información. Los ganchos pre-revprop-change y post-revprop-change pueden guardar un historial de los mensajes antiguos si realmente le preocupa, o enviar correos electrónicos con el mensaje de registro diff (esto es más común, en realidad), para que haya un pista de auditoría.