¿Por qué Git es mejor que Subversion?

votos
393

He estado usando Subversion durante algunos años y después de usar SourceSafe , me encanta Subversion. Combinado con TortoiseSVN , realmente no puedo imaginar cómo podría ser mejor.

Sin embargo, hay un creciente número de desarrolladores que afirman que Subversion tiene problemas y que deberíamos pasar a la nueva clase de sistemas de control de versiones distribuidas, como Git .

¿Cómo mejora Git a Subversion?

Publicado el 03/08/2008 a las 23:38
fuente por usuario
En otros idiomas...                            


30 respuestas

votos
548

Git no es mejor que Subversion. Pero tampoco es peor Es diferente.

La diferencia clave es que está descentralizado. Imagine que es un desarrollador en el camino, que desarrolla en su computadora portátil y desea tener control de fuente para que pueda retroceder 3 horas.

Con Subversion, usted tiene un problema: el repositorio SVN puede estar en una ubicación que no puede alcanzar (en su empresa, y no tiene Internet en este momento), no puede comprometerse. Si desea hacer una copia de su código, tiene que copiarlo / pegarlo literalmente.

Con Git, no tienes este problema. Su copia local es un repositorio, y puede comprometerse con ella y obtener todos los beneficios del control de la fuente. Cuando recupera la conectividad al repositorio principal, puede comprometerse contra él.

Esto se ve bien al principio, pero solo tenga en cuenta la complejidad añadida a este enfoque.

Git parece ser lo "nuevo, brillante, genial". No es para nada malo (hay una razón por la cual Linus lo escribió para el desarrollo del Linux Kernel después de todo), pero creo que muchas personas se suben al tren "Distributed Source Control" simplemente porque es nuevo y está escrito por Linus Torvalds, sin saber por qué / si es mejor.

Subversion tiene problemas, pero también lo hacen Git, Mercurial, CVS, TFS o lo que sea.

Editar: Entonces esta respuesta tiene ahora un año y todavía genera muchos votos positivos, así que pensé en agregar algunas explicaciones más. En el último año desde que escribimos esto, Git ha ganado mucho impulso y apoyo, especialmente desde sitios como GitHub realmente despegó. Estoy usando Git y Subversion hoy en día y me gustaría compartir algunas ideas personales.

Antes que nada, Git puede ser realmente confuso al principio cuando se trabaja de forma descentralizada. ¿Qué es un control remoto? y ¿Cómo configurar correctamente el repositorio inicial? son dos preguntas que surgen al principio, especialmente en comparación con el simple "svnadmin create" de SVN, el "git init" de Git puede tomar los parámetros --bare y --shared que parece ser la forma "correcta" de configurar un sistema centralizado repositorio. Hay razones para esto, pero agrega complejidad. La documentación del comando "checkout" es muy confusa para las personas que cambian de puesto: la forma "correcta" parece ser "git clone", mientras que "git checkout" parece cambiar de rama.

Git REALMENTE brilla cuando estás descentralizado. Tengo un servidor en casa y un portátil en la carretera, y SVN simplemente no funciona bien aquí. Con SVN, no puedo tener control de fuente local si no estoy conectado al repositorio (Sí, sé sobre SVK o sobre las formas de copiar el repositorio). Con Git, ese es el modo predeterminado de todos modos. Sin embargo, es un comando extra (las confirmaciones de commit de git localmente, mientras que el maestro de origen de git push envía la rama principal al remoto llamado "origen").

Como se dijo anteriormente: Git agrega complejidad. Dos modos de creación de repositorios, checkout vs. clone, commit vs. push ... Tienes que saber qué comandos funcionan localmente y cuáles funcionan con "the server" (supongo que la mayoría de la gente sigue prefiriendo un "master-repository" central) )

Además, las herramientas aún son insuficientes, al menos en Windows. Sí, hay un Complemento de Visual Studio, pero sigo usando git bash con msysgit.

SVN tiene la ventaja de que es MUCHO más fácil de aprender: existe su repositorio, todos los cambios hacia él, si sabe cómo crear, comprometer y pagar, y está listo para comenzar, y puede recoger cosas como ramificaciones, actualizaciones, etc. más adelante. en.

Git tiene la ventaja de que es MUCHO mejor adaptado si algunos desarrolladores no siempre están conectados al repositorio principal. Además, es mucho más rápido que SVN. Y por lo que he oído, el soporte de bifurcaciones y fusiones es mucho mejor (lo cual es de esperar, ya que estas son las principales razones por las que fue escrito).

Esto también explica por qué gana tanto zumbido en Internet, ya que Git es ideal para proyectos de código abierto: Just Fork it, realice los cambios en su propio Fork y luego solicite al responsable del proyecto original que realice los cambios. Con Git, esto solo funciona. Realmente, pruébalo en Github, es magia.

Lo que también veo son puentes Git-SVN: el repositorio central es un repositorio de Subversion, pero los desarrolladores trabajan localmente con Git y el puente luego envía sus cambios a SVN.

Pero incluso con esta larga adición, sigo de acuerdo con mi mensaje central: Git no es mejor o peor, simplemente es diferente. Si tiene la necesidad de "Control de fuente sin conexión" y la disposición a pasar más tiempo aprendiéndolo, es fantástico. Pero si tiene un control de origen estrictamente centralizado y / o tiene dificultades para introducir el control de código fuente porque sus compañeros de trabajo no están interesados, entonces brillará la simplicidad y la excelente herramienta (al menos en Windows) de SVN.

Respondida el 03/08/2008 a las 23:45
fuente por usuario

votos
145

Con Git, puedes hacer prácticamente cualquier cosa sin conexión, porque todos tienen su propio repositorio.

Hacer ramas y fusionarse entre ramas es realmente fácil.

Incluso si no tiene derechos de compromiso para un proyecto, aún puede tener su propio depósito en línea y publicar "solicitudes de envío" para sus parches. Todos los que les gustan sus parches pueden incorporarlos a su proyecto, incluidos los mantenedores oficiales.

Es trivial bifurcar un proyecto, modificarlo y seguir fusionándose en las correcciones de errores de la rama HEAD.

Git funciona para los desarrolladores del kernel de Linux. Eso significa que es realmente rápido (tiene que serlo) y se adapta a miles de contribuyentes. Git también usa menos espacio (hasta 30 veces menos espacio para el repositorio de Mozilla).

Git es muy flexible, muy TIMTOWTDI (hay más de una forma de hacerlo). Puede usar cualquier flujo de trabajo que desee y Git lo admitirá.

Finalmente, está GitHub , un gran sitio para alojar sus repositorios Git.

Inconvenientes de Git:

  • es mucho más difícil de aprender, porque Git tiene más conceptos y más comandos.
  • las revisiones no tienen números de versión como en subversión
  • muchos comandos de Git son crípticos, y los mensajes de error son muy hostiles al usuario
  • carece de una buena GUI (como la gran TortoiseSVN )
Respondida el 04/08/2008 a las 01:24
fuente por usuario

votos
110

Otras respuestas han hecho un buen trabajo al explicar las características principales de Git (que son geniales). Pero también hay muchas pequeñas formas que Git se comporta mejor y ayuda a mantener mi vida más sana. Estas son algunas de las pequeñas cosas:

  1. Git tiene un comando 'limpio'. SVN necesita desesperadamente este comando, teniendo en cuenta con qué frecuencia va a volcar archivos adicionales en su disco.
  2. Git tiene el comando 'bisect'. Es agradable.
  3. SVN crea directorios .svn en cada carpeta (Git solo crea un directorio .git). Cada script que escriba, y cada grep que haga, deberá escribirse para ignorar estos directorios .svn. También necesita un comando completo ("svn export") solo para obtener una copia correcta de sus archivos.
  4. En SVN, cada archivo y carpeta puede provenir de una revisión o rama diferente. Al principio, suena bien tener esta libertad. Pero lo que esto significa en realidad es que hay un millón de formas diferentes para que el pago y envío local se arruine por completo. (por ejemplo, si "svn switch" falla a la mitad, o si ingresa un comando incorrecto). Y la peor parte es que si alguna vez te encuentras en una situación en la que algunos de tus archivos provienen de un lugar y otros de otro, el "estado del svn" te dirá que todo es normal. Tendrá que hacer "svn info" en cada archivo / directorio para descubrir qué tan extrañas son las cosas. Si el "estado de git" te dice que las cosas son normales, entonces puedes confiar en que las cosas realmente son normales.
  5. Tienes que decirle a SVN cada vez que te mueves o borras algo. Git lo resolverá.
  6. Ignorar la semántica es más fácil en Git. Si ignora un patrón (como * .pyc), se ignorará para todos los subdirectorios. (Pero si realmente quieres ignorar algo para un solo directorio, puedes). Con SVN, parece que no hay una manera fácil de ignorar un patrón en todos los subdirectorios.
  7. Otro elemento que implica ignorar archivos. Git hace posible tener configuraciones de ignorar "privadas" (usando el archivo .git / info / exclude), que no afectará a nadie más.
Respondida el 26/09/2008 a las 01:18
fuente por usuario

votos
56

" Por qué Git es mejor que X " describe los diversos pros y contras de Git frente a otros SCM.

Brevemente:

  • Git rastrea contenido en lugar de archivos
  • Las sucursales son livianas y la fusión es fácil , y me refiero realmente fácil .
  • Se distribuye, básicamente, cada repositorio es una rama. Es mucho más fácil desarrollar al mismo tiempo y en colaboración que con Subversion, en mi opinión. También hace posible el desarrollo fuera de línea .
  • No impone ningún flujo de trabajo , como se ve en el sitio web vinculado anteriormente , hay muchos flujos de trabajo posibles con Git. Un flujo de trabajo al estilo de Subversion se imita fácilmente.
  • Los repositorios de Git son mucho más pequeños en tamaño de archivo que los repositorios de Subversion. Solo hay un directorio ".git", a diferencia de docenas de repositorios ".svn" (tenga en cuenta que Subversion 1.7 y posteriores ahora usan un solo directorio como Git).
  • El área de preparación es impresionante, le permite ver los cambios que va a cometer, cometer cambios parciales y hacer otras cosas.
  • El almacenamiento es invaluable cuando haces un desarrollo "caótico", o simplemente quieres corregir un error mientras trabajas en otra cosa (en una rama diferente).
  • Puede reescribir el historial , que es ideal para preparar conjuntos de parches y corregir sus errores ( antes de publicar los commits)
  • ... y mucho más.

Hay algunas desventajas:

  • Todavía no hay muchas GUI buenas. Es nuevo y Subversion ha existido por mucho más tiempo, así que esto es natural ya que hay algunas interfaces en desarrollo. Algunos buenos incluyen TortoiseGit y GitHub para Mac .
  • En este momento, no es posible realizar revisiones parciales / clones de repositorios (leí que está en desarrollo). Sin embargo, hay soporte de submódulo. Git 1.7+ admite revisiones dispersas .
  • Puede ser más difícil de aprender, aunque no encontré que este sea el caso (hace aproximadamente un año). Git ha mejorado recientemente su interfaz y es bastante fácil de usar.

En el uso más simple, Subversion y Git son prácticamente lo mismo. No hay mucha diferencia entre:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

y

git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Donde realmente brilla Git es ramificarse y trabajar con otras personas.

Respondida el 10/02/2009 a las 05:18
fuente por usuario

votos
54

Google Tech Talk: Linus Torvalds en git

http://www.youtube.com/watch?v=4XpnKHJAok8

La página de comparación de Wiki de Git

http://git.or.cz/gitwiki/GitSvnComparsion

Respondida el 03/08/2008 a las 23:44
fuente por usuario

votos
26

Bueno, está distribuido. Los puntos de referencia indican que es considerablemente más rápido (dada su naturaleza distribuida, las operaciones como diffs y los registros son todos locales, por supuesto es mucho más rápido en este caso), y las carpetas de trabajo son más pequeñas (lo cual todavía me sorprende).

Cuando trabajas en subversión o en cualquier otro sistema de control de revisión de cliente / servidor, esencialmente creas copias de trabajo en tu máquina revisando las revisiones. Esto representa una instantánea en el tiempo de cómo se ve el repositorio. Actualizas tu copia de trabajo a través de actualizaciones y actualizas el repositorio a través de confirmaciones.

Con un control de versión distribuida, no tiene una instantánea, sino la base de código completa. ¿Quieres hacer una diferencia con una versión de 3 meses? No hay problema, la versión de 3 meses todavía está en su computadora. Esto no solo significa que las cosas son mucho más rápidas, pero si estás desconectado de tu servidor central, aún puedes hacer muchas de las operaciones a las que estás acostumbrado. En otras palabras, no solo tiene una instantánea de una revisión determinada, sino toda la base de código.

Podrías pensar que Git ocuparía un montón de espacio en tu disco duro, pero de un par de puntos de referencia que he visto, en realidad lleva menos. No me preguntes cómo. Quiero decir, fue construido por Linus, él sabe una o dos cosas sobre los sistemas de archivos, supongo.

Respondida el 03/08/2008 a las 23:47
fuente por usuario

votos
22

Los principales puntos que me gustan de DVCS son los siguientes:

  1. Puedes cometer cosas rotas. No importa porque otros pueblos no los verán hasta que publiques. El tiempo de publicación es diferente al tiempo de confirmación.
  2. Debido a esto, puede comprometerse más a menudo.
  3. Puede fusionar la funcionalidad completa. Esta funcionalidad tendrá su propia rama. Todos los compromisos de esta rama estarán relacionados con esta funcionalidad. Puede hacerlo con un CVCS, sin embargo, con DVCS es el predeterminado.
  4. Puede buscar su historial (encontrar cuando se modificó una función)
  5. Puede deshacer un tirón si alguien arruina el repositorio principal, no necesita reparar los errores. Solo borra la fusión.
  6. Cuando necesite un control de fuente en cualquier directorio, haga lo siguiente: git init. y puedes comprometer, deshacer cambios, etc ...
  7. Es rápido (incluso en Windows)

La razón principal para un proyecto relativamente grande es la comunicación mejorada creada por el punto 3. Otros son buenos bonos.

Respondida el 04/09/2008 a las 12:06
fuente por usuario

votos
15

Lo curioso es que 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 de manera nativa Subversion, puedes 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 te animamos a que experimentes con ella.

Usar Git en un repositorio Svn me da beneficios:

  1. Puedo trabajar distribuido en varias máquinas, comprometiéndome y tirando de y hacia ellos
  2. Tengo un repositorio central de backup/public svn para que otros puedan verlo
  3. Y son libres de usar Git por su cuenta
Respondida el 02/10/2008 a las 14:05
fuente por usuario

votos
11

Todas las respuestas aquí son las esperadas, centradas en el programador, sin embargo, ¿qué ocurre si su empresa utiliza el control de revisión fuera del código fuente? Hay muchos documentos que no son códigos fuente que se benefician del control de versiones, y deben vivir cerca del código y no en otro CMS. La mayoría de los programadores no trabajan de forma aislada, trabajamos para empresas como parte de un equipo.

Con esto en mente, compare la facilidad de uso, tanto en la herramienta como en la capacitación del cliente, entre Subversion y git. No puedo ver un escenario donde cualquier sistema de control de revisión distribuido sea más fácil de usar o explicar a un no programador. Me gustaría que se demuestre que estoy equivocado, porque entonces podría evaluar git y tener la esperanza de que sea aceptado por personas que necesitan control de versiones que no son programadores.

Incluso entonces, si la gerencia nos pregunta por qué deberíamos pasar de un sistema de control de revisiones centralizado a uno distribuido, sería difícil dar una respuesta honesta, porque no lo necesitamos.

Descargo de responsabilidad: Me interesé en Subversion desde el principio (alrededor de v0.29), así que obviamente soy parcial, pero las compañías para las que he trabajado desde ese momento se están beneficiando de mi entusiasmo porque he alentado y apoyado su uso. Sospecho que así es como sucede con la mayoría de las compañías de software. Con tantos programadores subiendo al carro de git, me pregunto cuántas compañías se perderán los beneficios de usar el control de versiones fuera del código fuente. Incluso si tiene sistemas separados para diferentes equipos, se está perdiendo algunos de los beneficios, como la integración del seguimiento de problemas (unificado), al tiempo que aumenta los requisitos de mantenimiento, hardware y capacitación.

Respondida el 13/10/2009 a las 08:01
fuente por usuario

votos
9

Subversion sigue siendo un sistema de control de versiones mucho más usado, lo que significa que tiene un mejor soporte de herramientas. Encontrarás plugins SVN maduros para casi cualquier IDE , y existen buenas extensiones de explorador disponibles (como TurtoiseSVN). Aparte de eso, tendré que estar de acuerdo con Michael : Git no es mejor o peor que Subversion, es diferente.

Respondida el 18/09/2008 a las 19:44
fuente por usuario

votos
8

David Richards WANdisco Blog sobre la subversión / GIT

La aparición de GIT ha traído consigo una raza de fundamentalistas DVCS - el 'Gitterons' - que piensan que no sea nada GIT es una porquería. Los Gitterons parecen pensar la ingeniería de software que sucede en su propia isla y, a menudo hay que olvidar que la mayoría de las organizaciones no emplean los ingenieros de software de alto nivel en exclusiva. Eso está bien, pero no es como el resto del mercado piensa, y yo estoy feliz de demostrarlo: GIT, en el último aspecto tenía menos del tres por ciento del mercado, mientras que la subversión tiene en la región de cinco millones de usuarios y aproximadamente la mitad de el mercado global.

El problema que vimos fue que los Gitterons disparaban tiros (barato) en Subversion. Tweets como “subversión es tan [lenta / chungo / restrictiva / no huele bien / me mira de una manera divertida] y ahora tengo GIT y [todo funciona en mi vida / mi mujer se quedó embarazada / Tengo una novia después de 30 años de intentos / I ganó seis veces que se ejecuta en la mesa de blackjack]. Te dan la imagen.

Respondida el 17/09/2010 a las 19:22
fuente por usuario

votos
8

Una de las cosas sobre SubVersion que me molesta es que pone su propia carpeta en cada directorio de un proyecto, mientras que git solo pone una en el directorio raíz. No es que la gran cosa, pero pequeñas cosas como que se suman.

Por supuesto, SubVersion tiene Tortoise, que es [generalmente] muy agradable.

Respondida el 22/08/2008 a las 16:24
fuente por usuario

votos
7

Git también hace que las ramificaciones y las fusiones sean realmente fáciles. Subversion 1.5 acaba de agregar el seguimiento de fusión, pero Git es aún mejor. Con la ramificación de Git es muy rápido y económico. Hace que sea más factible crear una rama para cada nueva característica. Los repositorios de Oh y Git son muy eficientes con espacio de almacenamiento en comparación con Subversion.

Respondida el 09/08/2008 a las 04:22
fuente por usuario

votos
6

Easy Git tiene una página agradable que compara el uso real de Git y SVN, que le dará una idea de qué cosas puede hacer Git (o hacer más fácilmente) en comparación con SVN. (Técnicamente, esto se basa en Easy Git, que es un envoltorio liviano encima de Git).

Respondida el 22/08/2008 a las 16:19
fuente por usuario

votos
6

Se trata de la facilidad de uso / pasos necesarios para hacer algo.

Si estoy desarrollando un único proyecto en mi PC / laptop, git es mejor, porque es mucho más fácil de configurar y usar. No necesita un servidor, y no necesita seguir ingresando las URL del repositorio cuando realice las fusiones.

Si solo fueran 2 personas, diría que "git" también es más fácil, porque puedes empujar y tirar el uno del otro.

Sin embargo, una vez que hayas logrado ir más allá, buscaré la subversión, porque en ese momento necesitas configurar un servidor o ubicación "dedicada".

Puedes hacer esto tan bien con git como con SVN, pero los beneficios de git se ven compensados ​​por la necesidad de hacer pasos adicionales para sincronizar con un servidor central. En SVN, simplemente te comprometes. En git tienes que cometer git, luego git push. El paso adicional se vuelve molesto simplemente porque terminas haciéndolo mucho.

SVN también tiene el beneficio de mejores herramientas GUI, sin embargo, el ecosistema git parece estar alcanzándose rápidamente, por lo que no me preocuparía a largo plazo.

Respondida el 04/08/2008 a las 00:38
fuente por usuario

votos
5

Me gusta Git porque realmente ayuda al desarrollador de comunicaciones a desarrollar en un equipo mediano a grande. Como sistema de control de versiones distribuidas, a través de su sistema push / pull, ayuda a los desarrolladores a crear un ecosistema de código fuente que ayuda a administrar un gran grupo de desarrolladores que trabajan en un solo proyecto.

Por ejemplo, digamos que confías en 5 desarrolladores y solo extraes códigos de su repositorio. Cada uno de esos desarrolladores tiene su propia red de confianza desde donde extraen los códigos. Por lo tanto, el desarrollo se basa en el tejido de confianza de los desarrolladores donde la responsabilidad del código se comparte entre la comunidad de desarrollo.

Por supuesto, hay otros beneficios que se mencionan en otras respuestas aquí.

Respondida el 05/10/2008 a las 17:52
fuente por usuario

votos
5

Git y DVCS en general son excelentes para los desarrolladores que hacen una gran cantidad de códigos independientemente el uno del otro porque cada uno tiene su propia sucursal. Sin embargo, si necesita un cambio de otra persona, ella tiene que comprometerse con su repositorio local y luego debe presionar ese conjunto de cambios o debe sacarlo de ella.

Mi propio razonamiento también me hace pensar que DVCS hace las cosas más difíciles para el control de calidad y la gestión de lanzamientos si haces cosas como lanzamientos centralizados. Alguien tiene que ser responsable de hacer ese empuje / extracción desde el repositorio de todos los demás, resolver cualquier conflicto que se haya resuelto en el tiempo de confirmación inicial, luego hacer la compilación y luego tener a todos los demás desarrolladores sincronizando sus repositorios.

Todo esto se puede abordar con procesos humanos, por supuesto; DVCS acaba de romper algo que se solucionó mediante el control de versión centralizada para proporcionar algunas nuevas comodidades.

Respondida el 04/08/2008 a las 00:08
fuente por usuario

votos
4

Creo que Subversion es bien .. hasta que pueda empezar la fusión .. o hacer algo complicado .. o hacer cualquier subversión piensa que es complicado (como hacer consultas para averiguar qué ramas metido con un archivo en particular, cuando un cambio en realidad viene de, la detección de copia y pastas , etc) ...

No estoy de acuerdo con la respuesta ganadora, diciendo que el principal beneficio de GIT es un trabajo en línea - es ciertamente útil, pero es más como un extra para mi caso de uso. SVK puede trabajar fuera de línea también, todavía no hay duda para mí que uno a invertir mi tiempo de aprendizaje en).

Es sólo que es increíblemente potente y rápido y, así -después de acostumbrarse a los conceptos - muy útil (sí, en ese sentido: fácil de usar).

Para más detalles sobre una historia de fusión, ver esto: El uso de git-svn (o similar) * * simplemente para ayudar a cabo con un svn merge?

Respondida el 27/07/2010 a las 16:40
fuente por usuario

votos
4

Algunas respuestas han aludido a esto, pero quiero hacer 2 puntos explícitos:

1) La capacidad de hacer confirmaciones selectivas (por ejemplo, git add --patch). Si su directorio de trabajo contiene varios cambios que no forman parte del mismo cambio lógico, Git hace que sea muy fácil realizar una confirmación que incluya solo una parte de los cambios. Con Subversion, es difícil.

2) La capacidad de comprometerse sin hacer público el cambio. En Subversion, cualquier confirmación es inmediatamente pública y, por lo tanto, irrevocable. Esto limita en gran medida la capacidad del desarrollador para "comprometerse temprano, comprometerse a menudo".

Git es más que solo un VCS; también es una herramienta para desarrollar parches. Subversion es simplemente un VCS.

Respondida el 07/08/2009 a las 15:59
fuente por usuario

votos
3

Esta es la pregunta equivocada a estar preguntando. Es demasiado fácil centrarse en las verrugas de Git y formular un argumento acerca de por qué la subversión es ostensiblemente mejor, al menos para algunos casos de uso. El hecho de que git fue diseñado originalmente como un juego de construcción de control de versiones de bajo nivel y tiene una interfaz orientada a Linux-desarrollador barroca hace que sea más fácil para las guerras santas para ganar tracción y la legitimidad percibida. proponentes Git Muerte de un jugador con millones de ventajas de flujo de trabajo, que svn chicos proclaman innecesaria. Muy pronto todo el debate se enmarca como centralizado vs distribuido, que sirve a los intereses de la comunidad herramienta SVN empresa. Estas empresas, que normalmente ponen los artículos más convincentes acerca de la superioridad de la subversión en la empresa, dependen de la percepción de inseguridad de GIT y la empresa de preparación de SVN para el éxito a largo plazo de sus productos.

Pero aquí está el problema: La subversión es un callejón sin salida arquitectónica .

Mientras que usted puede tomar git y construir un reemplazo de la subversión centralizado con bastante facilidad, a pesar de ser de alrededor de más del doble de tiempo SVN nunca ha sido capaz de obtener registro de fusión, incluso básica de trabajo ni de lejos tan bien como lo hace en git. Una razón fundamental de esto es la decisión de diseño para que las ramas del mismo como directorios. No sé por qué fueron originalmente esta manera, sin duda hace que las cajas parciales muy simple. Por desgracia, también hace que sea imposible realizar un seguimiento de la historia correctamente. Ahora, evidentemente, que se supone que usar subversión convenciones esquema de repositorio para separar las ramas de directorios regulares, y SVN utiliza algunas heurísticas para hacer las cosas para los casos de uso diario. Pero todo esto es sólo tapar una decisión muy pobre y la limitación de diseño de bajo nivel. Ser capaz de hacer un diff de un repositorio a gota (en lugar de diferenciación de directorios-wise) es una funcionalidad básica y fundamental para un sistema de control de versiones y simplifica en gran medida los componentes internos, por lo que es posible la construcción de las características más inteligentes y útiles en la parte superior de la misma. Se puede ver en la cantidad de esfuerzo que se ha puesto en la subversión que se extiende, y sin embargo, hasta qué punto detrás de él es de la cosecha actual de VCSes modernos en términos de operaciones fundamentales como la resolución de combinación.

Ahora aquí está mi corazón, fieltro y asesoramiento agnóstico para cualquier persona que todavía cree Subversion es lo suficientemente bueno para el futuro previsible:

Subversion nunca ponerse al día con las nuevas razas de VCSes que han aprendido de los errores de RCS y CVS; se trata de una imposibilidad técnica a menos que rediseñar el modelo de repositorio desde el principio, pero entonces no sería realmente svn ¿verdad? Independientemente de la cantidad que cree que no las capacidades de un moderno VCS, su ignorancia no le protegerá de las trampas de la subversión, muchos de los cuales son situaciones que son imposibles o fácilmente resuelto en otros sistemas.

Es extremadamente raro que la inferioridad técnica de una solución es tan clara como lo es con SVN, ciertamente nunca habría afirmar tal opinión acerca de ganar-vs-Linux o emacs-vs-vi, pero en este caso es tan control de clareo, y la fuente es una herramienta tan fundamental en el arsenal del desarrollador, que siento es preciso señalar de forma inequívoca. Independientemente de la obligación de utilizar SVN por razones de organización, imploro a todos los usuarios de SVN no dejar que su mente lógica construir una falsa creencia de que VCSes más modernos sólo son útiles para grandes proyectos de código abierto. Independientemente de la naturaleza de su trabajo de desarrollo, si usted es un programador, usted será un programador más eficaz si se aprende cómo utilizar VCSes mejor diseñados, ya se trate de Git, Mercurial, Darcs, o muchos otros.

Respondida el 29/05/2011 a las 18:30
fuente por usuario

votos
3

Me encanta ser capaz de manejar las secciones locales de mi código fuente de Git, sin enturbiar el agua del depósito central. En muchos casos Voy pago y envío de código desde el servidor de Subversion y ejecutar un repositorio Git local, sólo para ser capaz de hacer esto. Es también grande que al inicializar un repositorio Git no contamina el sistema de archivos con un montón de carpetas .svn molestos por todas partes.

Y por lo que el apoyo de herramientas de Windows, TortoiseGit maneja los conceptos básicos muy bien, pero yo prefiero la línea de comandos a menos que quiera ver el registro. Me gusta mucho la forma de la tortuga de Git {|} SVN ayuda a la hora de leer los registros de cometer.

Respondida el 10/02/2010 a las 23:54
fuente por usuario

votos
3

Gracias al hecho de que no necesita comunicarse constantemente con un servidor central, casi todos los comandos se ejecutan en menos de un segundo (obviamente git push / pull / fetch son más lentos simplemente porque tienen que iniciar las conexiones SSH). La ramificación es mucho más fácil (un comando simple para ramificar, un comando simple para fusionar)

Respondida el 30/08/2008 a las 13:01
fuente por usuario

votos
2

Para las personas que buscan una buena interfaz gráfica de usuario de Git, Syntevo SmartGit podría ser una buena solución. Su propietario, pero gratuito para uso no comercial, se ejecuta en Windows / Mac / Linux e incluso soporta SVN utilizando algún tipo de puente git-svn, creo.

Respondida el 09/03/2011 a las 15:05
fuente por usuario

votos
2

Eric Sink de SourceGear escribió una serie de artículos sobre las diferencias entre los sistemas de control de versiones distribuidas y no distribuidas. Él compara los pros y los contras de los sistemas de control de versiones más populares. Lectura muy interesante.
Los artículos se pueden encontrar en su blog, www.ericsink.com :

Respondida el 13/10/2009 a las 14:36
fuente por usuario

votos
2

Subversion es muy fácil de usar. Nunca he encontrado en los últimos años un problema o que algo no funciona como se esperaba. También hay muchas herramientas de GUI excelentes y el soporte para la integración de SVN es grande.

Con Git obtienes un VCS más flexible. Puedes usarlo de la misma manera que SVN con un repositorio remoto donde comprometes todos los cambios. Pero también puede usarlo en su mayoría fuera de línea y solo enviar los cambios de vez en cuando al repositorio remoto. Pero Git es más complejo y tiene una curva de aprendizaje más pronunciada. Me encontré por primera vez comprometiéndome con sucursales incorrectas, creando sucursales indirectamente u obteniendo mensajes de error con poca información sobre el error y donde debo buscar con Google para obtener mejores informaciones. Algunas cosas simples como la sustitución de marcadores ($ Id $) no funcionan, pero GIT tiene un mecanismo de filtrado y enlace muy flexible para fusionar sus propios scripts y así obtener todo lo que necesita y más, pero necesita más tiempo y lectura de la documentación ;)

Si trabajas principalmente fuera de línea con tu repositorio local, no tienes respaldo si algo se pierde en tu máquina local. Con SVN, usted está trabajando principalmente con un repositorio remoto que también es la misma vez que su copia de seguridad en otro servidor ... Git puede funcionar de la misma manera, pero este no era el objetivo principal de Linus para tener algo como SVN2. Fue diseñado para los desarrolladores del kernel de Linux y las necesidades de un sistema de control de versiones distribuidas.

¿Git es mejor que SVN? Los desarrolladores que solo necesitan un poco de historial de versiones y un mecanismo de respaldo tienen una vida buena y fácil con SVN. Los desarrolladores que trabajan a menudo con sucursales, que prueban más versiones al mismo tiempo o que trabajan mayormente sin conexión se pueden beneficiar de las características de Git. Hay algunas funciones muy útiles, como la ocultación no encontrada con SVN, que pueden facilitar la vida. Pero por otro lado, no todas las personas necesitarán todas las características. Entonces no puedo ver a los muertos de SVN.

Git necesita una documentación mejor y los informes de errores deben ser más útiles. Además, las GUI útiles existentes son raras veces. Esta vez solo encontré 1 GUI para Linux con soporte para la mayoría de las funciones de Git (git-cola). La integración de Eclipse está funcionando, pero no es un lanzamiento oficial y no hay un sitio de actualización oficial (solo un sitio de actualización externo con versiones periódicas del tronco http://www.jgit.org/updates ) Así que la forma más preferida de usar Git en estos días es la linea de comando

Respondida el 13/10/2009 a las 14:14
fuente por usuario

votos
1

Por eso creo que es mejor que la subversión Git (al menos para los proyectos en los que trabajo), principalmente debido a su facilidad de uso y flujo de trabajo más sencillo:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Respondida el 22/10/2010 a las 17:25
fuente por usuario

votos
1

He estado habitando con Git tierra últimamente, y me gusta para proyectos personales, pero no me gustaría ser capaz de cambiar los proyectos de trabajo a ella todavía de Subversion dado el cambio en el pensamiento de la requerida por parte del personal, sin ningún beneficio apremiantes. Por otra parte el proyecto más grande que corremos en casa es extremadamente dependiente de svn: externos , que, por lo que he visto hasta ahora, no funciona tan bien y sin problemas en Git.

Respondida el 25/04/2010 a las 22:35
fuente por usuario

votos
1

http://subversion.wandisco.com/component/content/article/1/40.html

Creo que es bastante seguro decir que entre los desarrolladores, el SVN vs. Git argumento se ha estado librando desde hace algún tiempo, con todo el mundo tiene su propia opinión sobre cuál es mejor. Esto fue incluso ser educado en el de las preguntas durante nuestro seminario web sobre la subversión en 2010 y más allá.

Hyrum Wright, nuestro Director de código abierto y el Presidente de la Corporación de Subversion habla de las diferencias entre Subversion y Git, junto con otros sistemas de control de versiones distribuidos (DVCS).

También habla sobre los próximos cambios en Subversion, tales como copia de trabajo de nueva generación (WC-NG), que él cree que va a causar un número de usuarios Git para convertir de nuevo a la subversión.

Tener un reloj de su video y háganos saber lo que piensa, ya sea comentando en este blog, o mediante la publicación en los foros. El registro es sencillo y sólo tomará un momento!

Respondida el 10/02/2010 a las 19:51
fuente por usuario

votos
1

Git en Windows está bastante bien apoyado ahora.

Salida GitExtensions = http://code.google.com/p/gitextensions/

y el manual para una mejor experiencia de Windows Git.

Respondida el 10/02/2010 a las 17:29
fuente por usuario

votos
1

En primer lugar, el control de la versión simultánea parece ser un problema fácil de resolver. No es para nada. De todas formas...

SVN no es muy intuitivo. Git es aún peor. [especulación sarcástica] Esto podría deberse a que los desarrolladores, que les gustan los problemas difíciles como el control de versiones simultáneas, no tienen mucho interés en hacer una buena IU. [/ especulación sarcástica]

Los partidarios de SVN piensan que no necesitan un sistema distribuido de control de versiones. Yo también pensé eso. Pero ahora que usamos Git exclusivamente, soy un creyente. Ahora el control de versiones funciona para mí Y para el equipo / proyecto en lugar de solo trabajar para el proyecto. Cuando necesito una rama, me ramifico. Algunas veces es una rama que tiene una rama correspondiente en el servidor, y otras no. Sin mencionar todas las otras ventajas que tendré que estudiar (gracias en parte a la arcana y absurda falta de UI que es un sistema moderno de control de versiones).

Respondida el 03/01/2010 a las 13:45
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more