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

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 tiene un código crítico al que no quiere que nadie acceda, probablemente no querrá ponerlo bajo Git. Muchas empresas desean mantener su código centralizado y (supongo) todos los proyectos gubernamentales (serios) se encuentran en repositorios centrales.

Subversion es una sabiduría convencional

Esto quiere decir que muchas personas (especialmente los 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 codificado 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 le dice que borre todos los ideales convencionales de su mente y comience de nuevo.

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

SVN es un sistema de control de versiones. Tiene uno 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 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 revisar / clonar un subárbol
• SVN admite el control de acceso exclusivo svn lock , que es útil para archivos difíciles de fusionar
• SVN admite archivos binarios y archivos grandes con mayor facilidad (y no requiere copiar versiones antiguas en todas partes).
• Agregar un compromiso implica un número de pasos considerablemente menor, ya que no hay ningún impulso / empuje y tus cambios locales siempre se rebasan implícitamente en svn update .

Uno de los beneficios de Subversion sobre Git puede es que Subversion solo permite revisar subárboles. Con Git todo el repositorio es una unidad, solo puedes obtener todo o nada. Con el código modular, esto puede ser bastante bueno en comparación con los submódulos Git. (Aunque 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 se mostrará un directorio sin ningún archivo.

Puedo pensar en tres. Primero, es un poco más fácil de asimilar, especialmente para los desarrolladores. Conceptualmente, es mucho más simple que las opciones de DCVS . La segunda es la madurez, especialmente TortoiseSVN en Windows. Sin embargo, TortoiseHg se está recuperando rápidamente. En tercer lugar, la naturaleza de la bestia, solo una imagen de un sistema de archivos en el que puedes revisar cosas desde cualquier nivel del árbol, puede ser bastante útil en algunos escenarios, como la creación de versiones de una variedad de archivos de configuración muy diferentes entre docenas. de servidores sin docenas de repositorios.

Esto no quiere decir que no estemos moviendo todo el desarrollo a Mercurial.

• Los repositorios SVN son más manejables desde el punto de vista de los administradores ( ACL + métodos de autenticación + hotcopy + mirrors + vertederos)
• Las anotaciones SVN * son más fáciles de implementar y admitir
• svn:external tiene más potencia y flexibilidad que los submódulos
• Los árboles de repositorios basados en sistemas de archivos son más fáciles de usar que los repositorios monolíticos con separación lógica-única
• SVN tiene más diferentes herramientas de cliente
• SVN tiene interfaces web utilizables de 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 creo que merece ser una respuesta en sí misma.

La configuración cuidadosamente elegida de mi empresa para SVN requiere un bloqueo a nivel de archivo para editar el contenido, y nunca usa la combinación. Como resultado, varios desarrolladores compiten por bloqueos, y puede ser un gran cuello de botella, y nunca hay posibilidades de un conflicto de fusión.

SVN definitivamente hace un control de gestión de arriba a abajo mejor que Git. En mi migración de Skunkworks a Git (pedir perdón en lugar de permiso) he aterrorizado a mi gerente muchas veces con la idea de que no hay t cualquier servidor central de control maestro forzado por software para el que todos somos esclavos.

Mis razones:

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

Aprecio que estés buscando buena información, pero este tipo de pregunta simplemente invita: "Creo que Git es una gran victoria, 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 enormemente los beneficios de Git, pero en mi opinión, el control de la fuente no es algo que me mantenga despierto durante la noche.

Soy un cazador de ciervos, y cuando mis amigos y yo salimos, están armados hasta los dientes, cargados 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 trato de señalar es que si usted es un equipo pequeño que trabaja en un proyecto mediano a pequeño y ya está familiarizado con SVN, entonces utilícelo. Ciertamente es mejor que CVS o (shudder) SourceSafe , y no me toma más de cinco minutos configurar un repositorio. Git a veces puede ser una exageración.

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

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

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

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

Cuando no necesita ramificarse y fusionarse , 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 bifurcarse si se administran bien. Git está dirigido a casos complejos; por lo tanto, la mayoría de la documentación de Git asume que debe realizar operaciones complejas como bifurcar 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á relacionado con el hecho de que Git es intrínsecamente más poderoso y, por lo tanto, más complejo, y sería inútil hacerlo en el 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 código 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 fallar) y ser intuitivo. Aparte del hecho, que hubiera sido un gran esfuerzo lograr que se llevaran bien con un DVCS , había poco a ser ganado. Y con solo dos programadores en el equipo, tenía sentido para nosotros también seguir con SVN.

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

• Comprobaciones 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'. Debido a que los compromisos van al servidor, no hay posibilidad de error que pueda hacer que borre mis cambios una vez que se hayan confirmado. En git, los compromisos son locales, así que hasta que presione, aparece un 'rm -rf' y se acaba todo.
• Los confirmaciones son autenticados. 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 muy lejos.
• Los checkout compartidos funcionan mucho mejor. Cuando va a confirmar, le pide su nombre de usuario / contraseña, no tiene que recordar pasar ciertos argumentos de línea de comando. Algunas veces en el trabajo tenemos una máquina compartida con un svn 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 error.
• Diseño del repositorio. Puedes tener un proyecto general y subproyectos y elegir qué revisar cuando.
• Los números de revisión están incrementando enteros.
• Diseñado para el flujo de trabajo del repositorio central.

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

Velocidad. A veces se necesitan 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 verificarlo.

Publico esto como una respuesta en lugar de un comentario.

Admito que los DVCS están bastante en la tendencia en este momento, pero intentaré explicar por qué.

DVCS es mejor porque, como muchas personas han dicho, "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 de una manera que hace que SVN quede obsoleto.

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

• El proyecto a largo plazo se ha beneficiado mucho con DVCS, ya que utiliza menos gastos generales, permite una mejor administración (ramificación, etc.) y cuenta con el respaldo de hosts como el código de Google y github.

• Esos proyectos no son los únicos, hay otros tipos de proyectos que se desarrollan en compañías sin ninguna ayuda del mundo exterior o de Internet: todo se realiza internamente y, a menudo, a corto plazo. Un buen ejemplo: un videojuego. El código evoluciona rápidamente.

Para el último caso, los desarrolladores no necesitan realmente ramificaciones o características sofisticadas que DVCS puede ofrecer, solo quieren compartir el código fuente y los activos. El código que crean no es probable que se reutilice, porque hay una fecha límite. Se basan 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 la red y el dinero grande permiten el uso de un servidor centralizado que se ocupa de todo lo que es SVN, es una mala práctica, pero se realizan copias de seguridad, etc.
• SVN es simplemente más simple de usar, incluso si es la manera incorrecta: sincronizar archivos en pares sin redundancia no es un problema simple, y "hacerlo de la manera correcta" simplemente no puede hacerlo a tiempo si siempre quieres que sea perfecto.

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

Los DVCS están hechos para internet y para proyectos muy complejos. SVN son para proyectos pequeños, a corto plazo y en equipo. No es necesario 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 poco organizados de programadores profesionales altamente competentes. Ambas herramientas DVCS populares fomentan los 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 administración más centralizada y estrechamente acoplada, con más comunicación entre los desarrolladores y un mayor grado de control organizativo sobre las actividades de desarrollo diarias. 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 a Subversion apoyar equipos multidisciplinarios con miembros que no son programadores profesionales (por ejemplo, ingenieros de sistemas, ingenieros de algoritmos u otros especialistas en áreas temáticas).

Si su equipo está distribuido, los miembros trabajan desde su 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 lo hará. Ser un buen ajuste cultural.

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

Por supuesto, es posible configurar Git y Hg (tan potentes y flexibles como son) para hacer lo que quieras, pero definitivamente es más trabajo, y definitivamente son más difíciles de usar, especialmente para aquellos miembros de el equipo que, naturalmente, no estaría dispuesto a utilizar cualquier forma de cualquier de control de versiones.

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

A continuación se muestran las dos razones por las que aún sigo con SVN.

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

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

Git es excelente en la descentralización.

SVN tiene muchas herramientas integradas que se integran con él. Es común configurar su servidor SVN para que cuando ingrese una solución, mencione el número de error en el comentario del registro, y lo establezca automáticamente 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 solucionados 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 la confirmación se realiza y se inserta. Para la mayoría de los usos prácticos, esto es imposible por diseño en sistemas descentralizados, incluyendo git. Por supuesto, en git puedes hacer "enmendar - cambiar", pero eso no te ayuda después de que tu confirmación haya sido empujada a otra parte. En SVN, cuando edita el mensaje de registro, lo hace en el repositorio central que todos comparten, para que todos obtengan la edición y sin que cambie el identificador de la revisión.

La edición de 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 error). trabajo introducido en la revisión actual).

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