¿Debo usar SVN o Git? [cerrado]


321

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


55
Sí, git funciona en Mac. Si usa macports para instalarlo, incluso instalará un front end de mac en las interfaces de confirmación y exploración.
Seth Johnson

3

3
@Andre, porque puedes usar MonoDevelop, cambio de Vault a SVN para poder desarrollar software .NET en mi Mac o PC. No había cliente para Vault pero sí para SVN :-)
schmoopy


44
Github / bitbucket + sourcetree = cielo! - sourcetreeapp.com
thecodeassassin

Respuestas:


253

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


24
También podría echar un vistazo a Hg (Mercurio)
Joel

24
Las cosas han mejorado mucho desde octubre de 2008. Puede instalar TortoiseGit, obtener la última versión portátil de MSysGit y decirle a TortoiseGit dónde encontrarla. Hoy acabo de mudar mi gran repositorio de svn a git porque el pobre soporte para renombrar de svn finalmente me enojó lo suficiente.
Todos somos Mónica

44
Pasando 2 años, ahora tenemos algunas buenas herramientas de Windows. Actualmente estoy usando netbeans con MSysGit. También he tenido buena suerte con TortoiseGit. Creo que es lo suficientemente bueno como para ser utilizado en la producción. Teniendo en cuenta lo difícil que es gestionar conflictos simples en subversion git es una gran mejora.
Keyo

24
Usamos Git en Windows en gran medida y lo tenemos desde hace mucho tiempo. Git es absolutamente fantástico en Windows.
Charlie Flowers

13
@Oli Sería bueno actualizar su respuesta (especialmente sobre el cliente git de Windows) en función de los comentarios aquí y su experiencia. La respuesta actual parece sesgada ahora que han pasado 2-3 años desde que fue escrita.
amit

111

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


99
Yo, por otro lado, tuve algunos problemas con git en windows, le hizo cosas realmente extrañas a mi repositorio. Y estaba usando la versión más reciente en cygwin (era algo así como hace un mes).
Roman Plášil

77
@Roman: bueno, el puerto Cygwin no es lo mismo que el puerto win32 nativo. Espero que el puerto Cygwin esté mucho menos probado ...
SamB

49
"más funciones de las que probablemente usará" es una bandera roja en mi libro
BT

26
@ BT "bandera roja" No estoy de acuerdo. A menudo me encuentro deseando que hubiera una manera de hacer algo y después de un poco de búsqueda descubro que hay algunos comandos que no sabía sobre eso. También uso GIT en mi máquina Windows y todavía no he tenido problemas importantes.
testing123

@ testing123, pero no son características "que probablemente [n] usarás" porque realmente terminaste usándolas.
mulllhausen

77

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


10
No estoy en desacuerdo con usted en que git y svn son fundamentalmente diferentes, pero estoy en desacuerdo en muchos de sus puntos. svn puede haber sido escrito para reemplazar cvs, pero de ninguna manera están relacionados, mientras que cvs comenzó como scripts en la parte superior de RCS, por lo que hay una relación directa. Aún así, la persona que está citando tiene toda la razón, ambos gestionan fundamentalmente las revisiones de archivos, la implementación y el proceso en el que eso sucede (o cómo lo hace) son detalles de implementación. Es como la diferencia entre CRC y SHA1, fundamentalmente muy diferente, pero hacen lo mismo.
Erik Funkenbusch

37

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.


66
"corríjame si hay otro VCS que maneje archivos de 500 MB + de manera efectiva" - ¡Por supuesto, Perforce!
James Creasy

8
Perforce = no libre. Además, Perforce no está disponible para todas las plataformas.
WhyNotHugo

44
¿Por qué no colocar el repositorio SVN DENTRO de los contenedores de TrueCrypt? También podría hacer un túnel a través de ssh, y configurar el servidor para almacenar ese repositorio particular dentro de otro archivo truecrypt. Esto tiene la ventaja adicional de que puede realizar pagos parciales de ese repositorio.
WhyNotHugo

1
@Hugo, que yo sepa, el cliente Perforce está disponible para Windows, Unix, variantes de Linux, Mac, Amiga, BeOS, Cygwin, HPUX, IBM AS / 400, OS / 2, DEC VMS y Novell File Server. ¿Falta alguna plataforma relevante en la lista?
EIS

1
Sí, OpenBSD (y lo sabía por experiencia, no necesitaba googlear esto). Supongo que tampoco funcionará en maemo, aunque podría estar equivocado (y sí, uso git en maemo).
WhyNotHugo

25

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.


15
Git es increíblemente rápido en algunas operaciones, principalmente porque la operación solo afecta a su repositorio local. Un registro de Git, por ejemplo, no debe justamente ser comparado con un registro de SVN, debido a que un registro SVN es también la pulsación de un cambio a un repositorio de puesta en escena para el resto de su equipo. Eso requiere un éxito en la red, y comparar el compromiso sin red de Git con una transferencia de red huele a comparación inapropiada. Si se compromete y luego pierde el disco duro, con Git perdió su cambio. Está bien si eso es lo que esperas, pero no se espera en SCM no distribuidos.
Edwin Buck

1
@EdwinBuck Sin tomar en cuenta lo que Waqar hizo, en las pruebas, incluso teniendo en cuenta el tiempo de red, git tiende a ser más rápido: git-scm.com/about/small-and-fast
Sqeaky

Su punto de "Crear un repositorio es una operación trivial" es extremadamente importante, especialmente en Windows: en comparación con SVN, es mucho más fácil simular rápidamente un montón de repos distribuidos interconectados, todos conectados a un repositorio central (--bare) con Git que es hacer lo mismo con SVN (instalar la aplicación del servidor SVN de Windows, etc.). Además (bizarely) encuentro que Git es más consistente en todos los sistemas operativos: la línea de comandos está muy bien diseñada y, por lo tanto, es suficiente la mayor parte del tiempo (y prácticamente idéntica entre los sistemas operativos) frente a varias aplicaciones de cliente / servidor nativas de SVN ...
Shivan Dragon

1
El artículo wiki al que te refieres está lleno de errores. Por lo tanto, su respuesta es incorrecta. Voto negativo Hay una página de discusión en la wiki que se refiere a svnvsgit.com que explica por qué la comparación es incorrecta.
bahrep

Increíblemente rápido? He movido el proyecto ciforth de un cvs local a github. Este es un proyecto simple pero tiene un gran archivo fuente principal de 10,000 líneas. Si trato de culpar a este archivo, github cae en un tiempo de espera. Principalmente si uno no se contenta con decir rápido, e insiste en usar dicho calificador, no es una opinión equilibrada, lo que me hace sospechar de todo lo que dice. Groetjes Albert
Albert van der Horst

12

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.


11

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

3
Solo una nota: a partir de julio de 2011, Google Code admite Git de forma nativa.
Jeremy Salwen

9

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.


9

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.


8

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]


1
FYI: encierre la URL entre paréntesis angulares o reemplace los paréntesis con% 28 y% 29.
PhiLho

1
¿Funcionará la codificación URL para la sintaxis [] ()?
Hank Gay

16
Esto es incorrecto FUD. Git es fantástico en Windows. Y SVN es bastante malo en todas partes.
Charlie Flowers

66
Para todos los que me votaron negativamente, por favor regrese y mire los comentarios del desarrollador de alrededor de 2008: está bastante claro que a Linus y a la pandilla no les importaba admitir Windows. Eso está bien: tampoco quiero hacerlo, y mi software no es tan complejo como VCS que espera un comportamiento POSIXish del sistema de archivos. Sin embargo, parece injusto caracterizar mi declaración como FUD si nos fijamos en el contexto.
Hank Gay

2
Tal vez en 2008 git era malo en Windows, pero he estado usando msysgit desde 2009 y funciona perfectamente. Eso incluye gitk, el equivalente de escritorio fuera de línea de GitHub.
Dan Dascalescu

8

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.


Soy optimista de que el horizonte de irrelevancia será mucho más corto que unos pocos años.
Greg Hewgill

Sí, posiblemente solo sea un año. Git tiene una comunidad dinámica de desarrollo. Pero la subversión también. En uno o dos años, tendrá que mirar a ambos nuevamente para responder esta pregunta.
Mnementh

1
Ahora es uno o dos años después. ¿Cómo se ve? :)
Merlyn Morgan-Graham

3
Git carece de una extensión del modelo SCM distribuido a las otras fases de la tubería de desarrollo de software. No tenemos un buen modelo para los sistemas de compilación de versiones distribuidas, pruebas automatizadas distribuidas, control de calidad, control de versiones, etc. Solo estamos obteniendo algún soporte experimental para copias de seguridad distribuidas, y eso es después de décadas de investigación. Como tal, Git ofrece más al desarrollador y menos al proceso de desarrollo de software. Todas las implementaciones de Git finalmente bendicen a un repositorio para que sea el central, lo que simplifica las habilidades de Git más interesantes en facsímiles de SVN.
Edwin Buck

1
@hibbelig Git no tiene un repositorio central, cada repositorio es efectivamente (debido a su diseño distribuido) igual. Esto significa que usted puede reelaborar su canal de producción para posiblemente manejar todos los repositorios por igual, o bendecir artificialmente un repositorio para que tenga un estado "elevado artificialmente" (también conocido como el repositorio central ). Si hace lo primero, nadie sabe mucho sobre la construcción de canalizaciones paralelas donde un lanzamiento podría venir del escritorio de cualquier desarrollador, si hace lo último, la promesa de procesamiento distribuido es engañada por una convención centralizada.
Edwin Buck

6

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.


1
Sin embargo, esto está cambiando rápidamente. SVN pierde cuota de mercado, mientras que GIT gana: Por ejemplo: wikivs.com/wiki/Git_vs_Subversion#Popularity o programmers.stackexchange.com/questions/136079/…
Zelphir Kaltstahl

@Zelphir: No llamaría 7 años rápidamente, pero sí, GIT gana cuotas de mercado y es especialmente mejor para fusionar archivos.
Burkhard

4

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.


8
Definir 'nativamente'. msysgit funciona bien
Milan Babuškov

4

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.


4

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?


No llamaría a ningún desarrollador que copiara una carpeta controlada por SVN en otro proyecto para reutilizarla y no esperaba problemas obvios 'intermedios'. Los llamaría novicios. Sí, tiene razón, se debe a la subcarpeta .svn que le dice a SVN a qué repositorio pertenecen los archivos. Si el usuario eliminó esta subcarpeta .svn, podría importar la carpeta al nuevo proyecto SVN. Todavía estoy con SVN, pero mis necesidades son pocas. GIT es ideal para proyectos más grandes.
dyasta

3
Los últimos clientes svn no necesitan una .svncarpeta en cada subdirectorio. Eso "corrige" el error de copia antes de que ocurra.
Edwin Buck

4

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.


3

¿Has probado Bzr ?

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


Sin embargo, el soporte de Windows realmente necesita un poco de trabajo aquí. No tanto que no lo he estado usando con mucho gusto para toda mi programación reciente en Windows (de la que he estado haciendo bastante), o cualquier cosa, pero aún así ...
SamB

Casi el 100% de las veces con el sistema operativo, la gente "lo hizo [cualquier software] porque no le gustaba nada más en el mercado".
WhyNotHugo

@Hugo Con código abierto, si les gustara algo más en el mercado, contribuirían en lugar de hacer algo nuevo.
gritó el

Esto no es una respuesta a la pregunta en absoluto
Albert van der Horst

@AlbertvanderHorst No, no lo es, la pregunta se respondió en los días del salvaje oeste de SO, cuando nadie sabía nada mejor, y ofreció una alternativa. Discutible en mi prisa, parece que también he escrito mal el nombre de Canonical. ¡Me avergüenza!
Omar Kooheji

3

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


1
Sí, funciona muy bien. Lo instalé a través de MacPorts y lo uso a diario.
Greg Hewgill

Lo hace. Es excelente en cualquier sistema basado en POSIX (Unix, Linux, Solaris, BSD, etc.). Realmente es solo Windows donde radica el problema.
Oli

y el git-gui y el gitk probablemente funcionan de la misma manera en OS-X que en Linux y Windows. Al contrario de tortoiseSVN, ¿qué AFAIK es solo para Windows?
David Schmitt

@David Schmitt: bueno, tortoisesvn.tigris.org lo llama una "Extensión de Shell de Windows para Subversion", así que supongo que sí, sí ;-).
SamB

@Robert: ¿cómo fue tu experiencia con git en OS X?
David Schmitt


2

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.


1

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.