¿Debo usar SVN o Git? [cerrado]

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

SVN es un repositorio y muchos clientes. Git es un repositorio con muchos repositorios de clientes, cada uno con un usuario. Está descentralizado hasta un punto en el que las personas pueden rastrear sus propias ediciones localmente sin tener que enviar cosas a un servidor externo.

SVN está diseñado para ser más central donde Git se basa en que cada usuario tiene su propio repositorio de Git y esos repositorios vuelven a colocar los cambios en uno central. Por esa razón, Git ofrece a las personas un mejor control de la versión local.

Mientras tanto, puede elegir entre TortoiseGit , GitExtensions (y si aloja su repositorio git "central" en github, su propio cliente: GitHub para Windows ).

Si está buscando salir de SVN, es posible que desee evaluar Bazaar por un momento. Es uno de los sistemas de control de versiones de próxima generación que tiene este elemento distribuido. No depende de POSIX como git, por lo que hay compilaciones nativas de Windows y tiene algunas poderosas marcas de código abierto que lo respaldan.

Pero es posible que aún no necesite este tipo de características. Eche un vistazo a las características, ventajas y desventajas de los VCS distribuidos . Si necesita más que ofertas de SVN, considere una. Si no lo hace, es posible que desee seguir con la integración de escritorio superior de SVN (actualmente).

Nunca he entendido este concepto de "git no es bueno en Windows"; Me desarrollo exclusivamente bajo Windows y nunca he tenido ningún problema 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 realmente. Está disponible en casi todas las plataformas imaginables y tiene más funciones de las que probablemente usará.

Aquí hay una copia de una respuesta que hice de una pregunta duplicada desde entonces eliminada 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, el otro (Git) es un VCS distribuido basado en un gráfico de revisiones. Ver también Conceptos básicos de VCS .

Esa primera parte generó algunos comentarios mal informados que pretenden 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 administran directorios de datos versionados. SVN ofrece características de VCS (etiquetado y fusión), pero su etiqueta es solo una copia de directorio (como una rama, excepto que no "se supone" que toque nada en un directorio de etiquetas), y su fusión sigue siendo complicada, actualmente basada en meta -datos agregados para recordar lo que ya se ha fusionado.

• Git es una gestión de contenido de archivos (una herramienta hecha para fusionar archivos), desarrollada en un verdadero sistema de control de versiones , basado en un DAG ( gráfico acíclico dirigido ) de commits, donde las ramas son parte del historial de datos (y no un dato en sí mismo). ), y donde las etiquetas son verdaderos metadatos.

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

• Si tiene muchas fusiones complejas, hacerlo con SVN será más largo y más propenso a errores. Si tiene que crear muchas ramas, deberá administrarlas y fusionarlas, nuevamente mucho más fácilmente con Git que con SVN, especialmente si hay una gran cantidad de archivos involucrados (la velocidad se vuelve importante)
• Si tiene fusiones parciales para un trabajo en progreso, aprovechará el área de preparación de Git (índice) para comprometer solo lo que necesita, esconder el resto y avanzar en otra rama.
• si necesita desarrollo fuera de línea ... bueno, con Git siempre está "en línea", con su propio repositorio local, sea cual sea el flujo de trabajo que desee seguir con otros repositorios.

Aún así, los comentarios sobre esa vieja respuesta (eliminada) insistieron:

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

, a lo que respondí:

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

Puede lograr las mismas características técnicas (etiqueta, ramificación, fusión) con ambos, pero Git no se interpone en su camino y le permite concentrarse en el contenido de los archivos , sin pensar en la herramienta en sí.

Ciertamente no 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 mencionada anteriormente ):

• Una es una herramienta de revisión extendida, la otra un verdadero sistema de control de versiones.
• Uno es adecuado para proyectos monolíticos pequeños a medianos con flujo de trabajo de fusión simple y (no demasiado) versiones paralelas. SVN es suficiente para ese propósito, y es posible que no necesite todas las funciones de Git.
• El otro permite proyectos de medianos a grandes basados ​​en múltiples componentes ( un repositorio por componente ), con 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 retroadaptación, etc. Podrías hacerlo con SVN, pero estás mucho mejor con Git.
  SVN simplemente no puede administrar ningún proyecto de ningún tamaño con ningún flujo de trabajo de fusión. Git puede.

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

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

Dos ventajas clave de SVN que rara vez se citan:

1. Soporte de 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 en mis archivos TrueCrypt (corríjame si hay otro VCS que maneje archivos 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. Depósito parcial (subdir) checkout / checkin. Mercurial y bzr no admiten esto, y el soporte de git es limitado. Esto es malo en un entorno de equipo, pero invaluable si quiero verificar algo en otra computadora desde el directorio de mi casa.

Solo mis experiencias.

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 seguirlo, y he usado mucho, incluidos Subversion, Perforce, darcs, BitKeeper, ClearCase y CVS.
• Está completamente 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, luego sincronizarlo con cualquier número de otros repositorios.
• La sincronización puede ocurrir en muchos medios. Un canal SSH, a través de HTTP a través de WebDAV, por FTP, o enviando correos electrónicos con parches para que el destinatario los aplique. No es necesario un repositorio central, pero se puede usar.
• 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 ramas de Subversion llevan su historia completa. sin tener que realizar una copia extraña y recorrerla. Cuando uso Subversion, siempre me resulta incómodo mirar el historial de un archivo en la rama que ocurrió antes de que se creara la rama. de #git: spearce: No entiendo una cosa sobre SVN en la página. Hice una rama en SVN y al navegar por el historial se mostró todo el historial de un archivo en la rama
• La fusión de ramas es más simple y más automática en Git. En Subversion, debe recordar cuál fue la última revisión de la que se fusionó 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 juntas.
• Las fusiones de rama se registran como parte del historial adecuado del repositorio. Si fusiono dos ramas juntas, o si vuelvo a fusionar una rama en el tronco del que proviene, esa operación de fusión se registra como parte del historial del repositorio como realizada por mí, y cuándo. Es difícil disputar quién realizó la fusión cuando está justo allí en el registro.
• Crear un repositorio es una operación trivial: mkdir foo; cd foo; git init Eso es todo. Lo que significa que creo un repositorio Git para todo en estos días. Tiendo a usar un repositorio por clase. La mayoría de esos repositorios tienen menos de 1 MB en el disco, ya que solo almacenan notas de clase, tareas y mis respuestas de LaTeX.
• Los formatos de archivo 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 corromperse. No creo que nadie haya corrompido un repositorio de Git. He visto que Subversion con fsfs se corrompe a sí mismo. Y he visto a Berkley DB corrompirse 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 que es un formato muy simple. El repositorio CVS del proyecto Mozilla es de aproximadamente 3 GB; Se trata de 12 GB en 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 un poco de 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.

Instalaría un repositorio de Subversion. Al hacerlo de esta manera, los desarrolladores individuales pueden elegir si usar clientes Subversion o clientes Git (con git-svn). El uso git-svnno le brinda todos los beneficios de una solución Git completa, pero sí brinda a los desarrolladores individuales un gran control sobre su propio flujo de trabajo.

Creo que pasará un tiempo relativamente corto antes de que Git funcione tan bien en Windows como en Unix y Mac OS X (ya que lo solicitó).

Subversion tiene excelentes herramientas para Windows, como TortoiseSVN para la integración de Explorer y AnkhSVN para la integración de Visual Studio.

Lo curioso es: alojo proyectos en Subversion Repos, pero accedo a ellos a través del comando Git Clone.

Lea Desarrollar con Git en un proyecto de código de Google

Aunque Google Code habla Subversion de forma nativa, puede usar Git fácilmente durante el desarrollo. La búsqueda de "git svn" sugiere que esta práctica está muy extendida, y nosotros también lo alentamos a que experimente con ella.

Usar Git en un repositorio Svn me da beneficios:

1. Puedo trabajar distribuido en varias máquinas, comprometiéndome y tirando de ellas
2. Tengo un repositorio svn central backup/public para que otros puedan ver
3. Y son libres de usar Git para su propio

Realmente no respondo a su pregunta, pero si desea los beneficios del Control de revisión distribuido , parece que lo hace, y está usando Windows, creo que sería mejor usar Mercurial en lugar de que Git como Mercurial tenga mucho mejor soporte de Windows. Mercurial también tiene un puerto Mac.

Si su equipo ya está familiarizado con los softwares de control de versiones y fuentes como cvs o svn, entonces, para un proyecto simple y pequeño (como usted dice que es), le recomendaría que se adhiera a SVN. Estoy realmente cómodo con svn, pero para el proyecto de comercio electrónico actual que estoy haciendo en django, decidí trabajar en git (estoy usando git en modo svn, es decir, con un repositorio centralizado al que presiono y extraigo para colaborar con al menos otro desarrollador). El otro desarrollador se siente cómodo con SVN, y aunque las experiencias de otros pueden diferir, los dos lo estamos pasando muy mal abrazando git para este pequeño proyecto. (Ambos somos usuarios hardcore de Linux, si es que importa).

Su kilometraje puede variar, por supuesto.

Definitivamente svn, dado que Windows es, en el mejor de los casos, un ciudadano de segunda clase en el mundo de git(ver http://en.wikipedia.org/wiki/Git_(software)#Portability para más detalles).

ACTUALIZACIÓN: Perdón por el enlace roto, pero dejé de intentar que SO funcione con URI que contienen paréntesis. [enlace arreglado ahora. -ed]

El punto principal es que Git es un VCS distribuido y Subversion centralizado. Los VCS distribuidos son un poco más difíciles de entender, pero tienen muchas ventajas. Si no necesita estas ventajas, Subversion puede ser la mejor opción.

Otra pregunta es el soporte de herramientas. ¿Qué VCS está mejor respaldado por las herramientas que planea usar?

EDITAR: Hace tres años respondí de esta manera:

Y Git funciona en Windows en este momento solo a través de Cygwin o MSYS . Subversion soportó Windows desde el principio. Como las soluciones git para Windows pueden funcionar para usted, puede haber problemas, ya que la mayoría de los desarrolladores de Git trabajan con Linux y no tenían la portabilidad en mente desde el principio. Por el momento, preferiría Subversion para el desarrollo en Windows. En unos pocos años esto puede ser irrelevante.

Ahora el mundo ha cambiado un poco. Git tiene una buena implementación en Windows ahora. Aunque no probé exhaustivamente en Windows (ya que ya no uso este sistema), estoy bastante seguro de que todos los VCS principales (SVN, Git, Mercurial, Bazaar) tienen una implementación adecuada de Windows ahora. Esta ventaja para SVN se ha ido. Los otros puntos (Centralizado vs. Distribuido y la verificación de soporte de herramientas) siguen siendo válidos.

Optaría por SVN ya que está más extendido y es más conocido.

Supongo que Git sería mejor para el usuario de Linux.

Git no es compatible de forma nativa con Windows, por el momento. Está optimizado para sistemas Posix. Sin embargo, ejecutar Cygwin o MinGW le permite ejecutar Git con éxito.

Hoy en día prefiero Git sobre SVN, pero lleva un tiempo superar el umbral si vienes de CVS, SVN land.

Probablemente elegiría Git porque siento que es mucho más poderoso que SVN. Hay servicios de hospedaje de códigos baratos disponibles que funcionan muy bien para mí, no tiene que hacer copias de seguridad ni ningún trabajo de mantenimiento, GitHub es el candidato más obvio.

Dicho esto, no sé nada sobre la integración de Visual Studio y los diferentes sistemas SCM. Me imagino que la integración con SVN es notablemente mejor.

He usado SVN durante mucho tiempo, pero cada vez que usé Git, sentí que Git es mucho más potente, liviano y, aunque involucra un poco de curva de aprendizaje, es mejor que SVN.

Lo que he notado es que cada proyecto SVN, a medida que crece, se convierte en un proyecto de gran tamaño a menos que se exporte. Mientras que, el proyecto GIT (junto con los datos de GIT) tiene un tamaño muy ligero.

En SVN, he tratado con desarrolladores desde principiantes hasta expertos, y los novatos e intermedios parecen presentar conflictos de archivos si copian una carpeta de otro proyecto SVN para volver a usarla. Mientras que, creo que en Git, simplemente copia la carpeta y funciona, porque Git no introduce carpetas .git en todas sus subcarpetas (como lo hace SVN).

Después de lidiar mucho con SVN desde hace mucho tiempo, finalmente estoy pensando en trasladarme a mis desarrolladores y a mí a Git, ya que es fácil colaborar y fusionar el trabajo, y una gran ventaja es que los cambios de una copia local pueden comprometerse tanto deseado, y finalmente empujado a la rama en el servidor de una vez, a diferencia de SVN (donde tenemos que confirmar los cambios de vez en cuando en el repositorio en el servidor).

¿Alguien que pueda ayudarme a decidir si realmente debería ir con Git?

Todo se reduce a esto:

¿Su desarrollo será lineal? Si es así, debes seguir con Subversion.

Si, por otro lado, su desarrollo no será lineal, lo que significa que necesitará crear ramificaciones para diferentes cambios, y luego fusionar dichos cambios nuevamente en la línea de desarrollo principal (conocida por Git como la rama maestra), entonces Git lo hará MUCHO más para ti.

¿Has probado Bzr ?

Es bastante bueno, connonical (las personas que hacen Ubuntu) lo hicieron porque no les gustaba nada más en el mercado ...

¿Puedo ampliar la pregunta y preguntar si Git funciona bien en MacOS?

Responder a los comentarios: Gracias por la noticia, tenía muchas ganas de probarla. Lo instalaré en casa en mi Mac.

Hay un video interesante en YouTube sobre esto. Es del propio Linus Torwalds: Goolge Tech Talk: Linus Torvalds en git

SVN parece una buena opción en Windows, como lo señalan otras personas.

Si alguno de sus desarrolladores quiere probar GIT, siempre puede usar GIT-SVN donde el repositorio SVN se recrea en un repositorio GIT. Entonces debería poder trabajar localmente con GIT y luego usar SVN para publicar sus cambios en el repositorio principal.

Tienes que ir con un DVCS, es como un salto cuántico en la gestión de la fuente. Personalmente uso Monotone y su tiempo de desarrollo acelerado no tiene fin. Lo estamos usando para Windows, Linux y Mac y ha sido muy estable. Incluso tengo buildbot haciendo compilaciones nocturnas del proyecto en cada una de las plataformas.

El DVCS mientras se distribuye generalmente significa que creará un servidor central solo para que las personas empujen los cambios hacia y desde.