¿Debo usar SVN o Git? [cerrado]

Estoy comenzando un nuevo proyecto distribuido. ¿Debería usar SVN o Git y por qué?

Oct 02 '08 16:10 rudigrobler

Nunca entendí este concepto de que "git no es bueno en Windows"; Desarrollo exclusivamente en Windows y nunca he tenido problemas con git.

Definitivamente recomendaría git sobre subversion; Es simplemente mucho más versátil y permite el "desarrollo fuera de línea" de una manera que la subversión nunca podría. Está disponible en casi todas las plataformas imaginables y tiene más funciones de las que probablemente jamás utilizará.

Oct 02 '2008 10:10 Dark Shikari

Aquí hay una copia de una respuesta que hice a una pregunta duplicada que luego eliminé sobre Git vs. SVN (septiembre de 2009).

¿Mejor? Aparte del enlace habitual WhyGitIsBetterThanX , son diferentes:

uno es un VCS central basado en una copia barata para ramas y etiquetas y el otro (Git) es un VCS distribuido basado en un gráfico de revisiones. Véase también Conceptos básicos de VCS .

Esa primera parte generó algunos comentarios mal informados, pretendiendo que el propósito fundamental de los dos programas (SVN y Git) es el mismo, pero que se han implementado de manera bastante diferente.
Para aclarar la diferencia fundamental entre SVN y Git , permítanme reformular:

• SVN es la tercera implementación de un control de revisión : RCS, luego CVS y finalmente SVN gestionan directorios de datos versionados. SVN ofrece funciones VCS (etiquetado y fusión), pero su etiqueta es solo una copia del directorio (como una rama, excepto que "se supone" que no debes tocar nada en un directorio de etiquetas), y su fusión aún es complicada, actualmente basada en meta -datos agregados para recordar lo que ya se ha fusionado.

• Git es una herramienta de gestión de contenido de archivos (una herramienta creada para fusionar archivos), evolucionada hasta convertirse en un verdadero Sistema de Control de Versiones , basado en un DAG ( Gráfico Acíclico Dirigido ) de confirmaciones, donde las ramas son parte del historial de datos (y no de un dato en sí). ), y donde las etiquetas son verdaderos metadatos.

Decir que no son "fundamentalmente" diferentes porque se puede lograr lo mismo, resolver el mismo problema, es... completamente falso en muchos niveles.

• Si tiene muchas fusiones complejas, realizarlas con SVN será más largo y más propenso a errores. si tiene que crear muchas ramas, necesitará administrarlas y fusionarlas, de nuevo mucho más fácilmente con Git que con SVN, especialmente si se trata de una gran cantidad de archivos (la velocidad entonces se vuelve importante)
• Si tiene fusiones parciales para un trabajo en progreso, aprovechará el área de preparación (índice) de Git para confirmar solo lo que necesita, guardar el resto y continuar con otra rama.
• si necesitas desarrollo fuera de línea... bueno con Git siempre estás "en línea", con tu propio repositorio local, sea cual sea el flujo de trabajo que quieras seguir con otros repositorios.

Aún así, los comentarios sobre esa antigua respuesta (eliminada) insistían:

VonC: Usted está confundiendo una diferencia fundamental en la implementación (las diferencias son muy fundamentales, ambos estamos claramente de acuerdo en esto) con una diferencia en el propósito.
Ambas son herramientas utilizadas para el mismo propósito: es por eso que muchos equipos que anteriormente han usado SVN han podido deshacerse de él con bastante éxito en favor de Git.
Si no resolvieran el mismo problema, esta sustituibilidad no existiría.

, a lo que respondí:

"sustituibilidad"... término interesante ( usado en programación de computadoras ).
Por supuesto, Git no es un subtipo de SVN.

Puedes lograr las mismas características técnicas (etiquetar, bifurcar, fusionar) con ambos, pero Git no se interpone en tu camino y te permite concentrarte en el contenido de los archivos , sin pensar en la herramienta en sí.

Ciertamente no se puede (siempre) simplemente reemplazar SVN por Git "sin alterar ninguna de las propiedades deseables de ese programa (corrección, tarea realizada, ...)" (que es una referencia a la definición de sustituibilidad antes mencionada ):

• Una es una herramienta de revisión extendida y la otra un verdadero sistema de control de versiones.
• Uno es adecuado para proyectos monolíticos pequeños y medianos con un flujo de trabajo de combinación simple y (no demasiadas) versiones paralelas. SVN es suficiente para ese propósito y es posible que no necesite todas las funciones de Git.
• El otro permite proyectos medianos a grandes basados ​​en múltiples componentes ( un repositorio por componente ), con una gran cantidad de archivos para fusionar entre múltiples ramas en un flujo de trabajo de fusión complejo, versiones paralelas en ramas, fusiones de actualización, etc. Podrías hacerlo con SVN, pero estarás mucho mejor con Git.
  SVN simplemente no puede gestionar ningún proyecto de cualquier tamaño con ningún flujo de trabajo de fusión. Git puede.

Una vez más, su naturaleza es fundamentalmente diferente (lo que luego conduce a una implementación diferente, pero ese no es el punto).
Uno ve el control de revisiones como directorios y archivos, el otro solo ve el contenido del archivo (¡tanto es así que los directorios vacíos ni siquiera se registrarán en Git!).

El objetivo final general puede ser el mismo, pero no se pueden utilizar de la misma manera ni se puede resolver la misma clase de problema (en alcance o complejidad).

Mar 30 '2010 22:03 VonC

2 ventajas clave de SVN que rara vez se citan:

1. Soporte para archivos grandes. Además del código, uso SVN para administrar mi directorio de inicio. SVN es el único VCS (distribuido o no) que no se ahoga con mis archivos TrueCrypt (corríjame si hay otro VCS que maneja archivos de más de 500 MB de manera efectiva). Esto se debe a que las comparaciones de diferencias se transmiten (este es un punto muy esencial). Rsync es inaceptable porque no es bidireccional.

2. Registro/registro parcial del repositorio (subdirectorio). Mercurial y bzr no admiten esto y el soporte de git es limitado. Esto es malo en un entorno de equipo, pero tiene un valor incalculable si quiero comprobar algo en otra computadora desde el directorio de mi casa.

Solo mis experiencias.

Aug 11 '2009 16:08 user154489

Después de investigar más y revisar este enlace: https://git.wiki.kernel.org/articles/g/i/t/GitSvnComparison_cb82.html

(Algunos extractos a continuación):

• Es increíblemente rápido. Ningún otro SCM que he usado ha podido seguirle el ritmo y he usado muchos, incluidos Subversion, Perforce, darcs, BitKeeper, ClearCase y CVS.
• Está totalmente distribuido. El propietario del repositorio no puede dictar cómo trabajo. Puedo crear ramas y confirmar cambios mientras estoy desconectado en mi computadora portátil y luego sincronizarlo con cualquier cantidad de otros repositorios.
• La sincronización puede ocurrir a través de muchos medios. Un canal SSH, a través de HTTP a través de WebDAV, por FTP o mediante el envío de correos electrónicos con parches que aplicará el destinatario del mensaje. No es necesario un repositorio central, pero se puede utilizar.
• Las sucursales son incluso más baratas que en Subversion. Crear una rama es tan simple como escribir un archivo de 41 bytes en el disco. Eliminar una rama es tan simple como eliminar ese archivo.
• A diferencia de las sucursales de Subversion, llevan consigo su historia completa. sin tener que realizar una copia extraña y recorrer la copia. Cuando usaba Subversion, siempre me resultaba incómodo mirar el historial de un archivo en una rama que ocurrió antes de que se creara la rama. de #git: Spearce: No entiendo nada sobre SVN en la página. Hice una rama en SVN y al explorar el historial se mostró todo el historial, un archivo en la rama.
• La fusión de ramas es más sencilla y automática en Git. En Subversion necesitas recordar cuál fue la última revisión desde la que fusionaste para poder generar el comando de fusión correcto. Git hace esto automáticamente y siempre lo hace bien. Lo que significa que hay menos posibilidades de cometer un error al fusionar dos ramas.
• Las fusiones de sucursales se registran como parte del historial adecuado del repositorio. Si fusiono dos ramas, o si vuelvo a fusionar una rama con el tronco de donde vino, esa operación de fusión se registra como parte del historial del repositorio como si la hubiera realizado yo y cuándo. Es difícil discutir quién realizó la fusión cuando está ahí en el registro.
• Crear un repositorio es una operación trivial: mkdir foo; cdfo; git init Eso es todo. Lo que significa que hoy en día creo un repositorio Git para todo. Tiendo a utilizar un repositorio por clase. La mayoría de esos repositorios tienen menos de 1 MB en disco, ya que solo almacenan notas de conferencias, tareas y mis respuestas de LaTeX.
• Los formatos de archivos internos del repositorio son increíblemente simples. Esto significa que la reparación es muy fácil de hacer, pero aún mejor porque es tan simple que es muy difícil que se corrompa. No creo que a nadie se le haya dañado nunca un repositorio de Git. He visto Subversion con fsfs corrupto. Y he visto a Berkley DB corromperse demasiadas veces como para confiar mi código al backend bdb de Subversion.
• El formato de archivo de Git es muy bueno para comprimir datos, a pesar de ser un formato muy simple. El repositorio CVS del proyecto Mozilla tiene aproximadamente 3 GB; Son aproximadamente 12 GB en el formato fsfs de Subversion. En Git son alrededor de 300 MB.

Después de leer todo esto, estoy convencido de que Git es el camino a seguir (aunque existe una pequeña curva de aprendizaje). También he usado Git y SVN en plataformas Windows.

Me encantaría escuchar lo que otros tienen que decir después de leer lo anterior.

Nov 13 '2010 09:11 Waqar