¿Por qué Git es mejor que Subversion?

08-06-2019
|

Pregunta

he estado usando Subversión durante algunos años y después de usar Fuente segura, Me encanta Subversion.Combinado con TortugaSVN, Realmente no puedo imaginar cómo podría ser mejor.

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

¿Cómo mejora Git a Subversion?

Solución

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

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

Con Subversion, tienes un problema:El repositorio SVN puede estar en una ubicación a la que no puede acceder (en su empresa y no tiene Internet en este momento), no puede comprometerse.Si desea hacer una copia de su código, literalmente debe copiarlo y pegarlo.

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 código fuente.Cuando recupere la conectividad con el repositorio principal, podrá comprometerse con él.

Esto parece bueno al principio, pero tenga en cuenta la complejidad adicional de este enfoque.

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

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

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

En primer lugar, Git puede resultar muy confuso al principio cuando se trabaja de forma descentralizada.¿Qué es un control remoto?y ¿Cómo configurar correctamente el repositorio inicial?Hay 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, lo que parece ser la forma "adecuada" de configurar una configuración centralizada. repositorio.Hay razones para esto, pero añade complejidad.La documentación del comando "checkout" es muy confusa para las personas que cambian: 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 una computadora portátil mientras estoy de viaje, y SVN simplemente no funciona bien aquí.Con SVN, no puedo tener control de fuente local si no estoy conectado al repositorio (Sí, conozco SVK o las formas de copiar el repositorio).Con Git, ese es el modo predeterminado de todos modos.Sin embargo, es un comando adicional (git commit confirma localmente, mientras que git push origin master empuja la rama maestra al control remoto llamado "origen").

Como se dijo anteriormente:Git agrega complejidad.Dos modos de crear repositorios, checkout vs.clonar, comprometer vs.empujar...Tienes que saber qué comandos funcionan localmente y cuáles funcionan con "el servidor" (supongo que a la mayoría de la gente todavía le gusta un "repositorio maestro" central).

Además, las herramientas siguen siendo 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 sencillo de aprender:Ahí está su repositorio, todos los cambios se dirigen hacia él, si sabe cómo crear, confirmar y pagar y está listo para comenzar y puede recoger cosas como bifurcaciones, actualizaciones, etc.mas tarde.

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

Esto también explica por qué genera tanta expectación en Internet, ya que Git se adapta perfectamente a proyectos de código abierto:Simplemente bifurque, confirme sus cambios en su propia bifurcación y luego pídale al responsable del proyecto original que realice sus cambios.Con Git, esto simplemente funciona.De verdad, pruébalo en Github, es mágico.

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 manteniendo mi mensaje central:Git no es mejor ni peor, simplemente es diferente.Si necesita "Control de fuente sin conexión" y está dispuesto a dedicar más tiempo a aprenderlo, es fantástico.Pero si tiene un control de fuente estrictamente centralizado y/o tiene dificultades para introducir el control de fuente en primer lugar porque sus compañeros de trabajo no están interesados, entonces la simplicidad y las excelentes herramientas (al menos en Windows) de SVN brillan.

Otros consejos

Con Git, puedes hacer prácticamente cualquier cosa sin conexión, porque cada uno tiene su propio repositorio.

Crear ramas y fusionarlas es realmente fácil.

Incluso si no tiene derechos de confirmación para un proyecto, aún puede tener su propio repositorio en línea y publicar "solicitudes push" para sus parches.Todos a quienes les gusten sus parches pueden incorporarlos a su proyecto, incluidos los mantenedores oficiales.

Es trivial bifurcar un proyecto, modificarlo y seguir fusionándolo 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 utiliza 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 utilizar cualquier flujo de trabajo que desee y Git lo admitirá.

Finalmente, hay GitHub, un gran sitio para alojar tus repositorios Git.

Desventajas 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 subversion
Muchos comandos de Git son crípticos y los mensajes de error son muy poco amigables para el usuario.
carece de una buena GUI (como la gran TortugaSVN)

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

Git tiene un comando "limpio".SVN necesita desesperadamente este comando, considerando la frecuencia con la que volcará archivos adicionales en su disco.
Git tiene el comando 'bisectar'.Es agradable.
SVN crea directorios .svn en cada carpeta (Git solo crea uno directorio .git).Cada script que escriba y cada grep que realice deberá escribirse para ignorar estos directorios .svn.También necesita un comando completo ("svn export") sólo para obtener una copia sana de sus archivos.
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 realmente significa es que hay un millón de formas diferentes de arruinar completamente su caja local.(por ejemplo, si "svn switch" falla a la mitad o si ingresa un comando incorrecto).Y la peor parte es: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 svn" te dirá que todo es normal.Necesitará hacer "svn info" en cada archivo/directorio para descubrir qué tan raras 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.
Tienes que informar a SVN cada vez que mueves o eliminas algo.Git simplemente lo resolverá.
Ignorar la semántica es más fácil en Git.Si ignora un patrón (como *.pyc), se ignorará durante todo subdirectorios.(Pero si realmente desea ignorar algo para un solo directorio, puede hacerlo).Con SVN, parece que no hay una manera fácil de ignorar un patrón en todos los subdirectorios.
Otro elemento relacionado con ignorar archivos.Git hace posible ignorar configuraciones "privadas" (usando el archivo .git/info/exclude), lo que no afectará a nadie más.

"Por qué Git es mejor que X" describe las diversas ventajas y desventajas de Git frente a otros SCM.

Brevemente:

pistas de git contenido en lugar de archivos
Las ramas son livianas. y fusionarse es fácil, y quiero decir realmente fácil.
Está distribuido, básicamente cada repositorio es una rama.En mi opinión, es mucho más fácil desarrollar de forma simultánea y colaborativa que con Subversion.También hace desconectado desarrollo posible.
Él 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 estilo Subversion se imita fácilmente.
Los repositorios de Git son mucho más pequeño en tamaño de archivo que los repositorios de Subversion.Sólo hay un directorio ".git", a diferencia de docenas de repositorios ".svn" (tenga en cuenta Subversion 1.7 y superiores ahora usa un solo directorio como Git.)
El puesta en escena El área es increíble, te permite ver los cambios que realizarás, realizar cambios parciales y hacer otras cosas.
Escondite es invaluable cuando haces un desarrollo "caótico", o simplemente quieres corregir un error mientras todavía estás trabajando en otra cosa (en una rama diferente).
Puede reescribir la historia, que es excelente para preparar conjuntos de parches y corregir errores (antes publicas los commits)
... y un lote más.

Hay algunas desventajas:

Todavía no hay muchas GUI buenas para ello.Es nuevo y Subversion existe desde hace mucho más tiempo, por lo que esto es natural ya que hay algunas interfaces en desarrollo.Algunos buenos incluyen TortugaGit y GitHub para Mac.
~~Los pagos/clones parciales de repositorios no son posibles en este momento (leí que está en desarrollo).Sin embargo, hay soporte para submódulos.~~ Git 1.7+ admite pagos dispersos.
Puede que sea más difícil de aprender, aunque no encontré que este fuera 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 simplista, Subversion y Git son prácticamente iguales.No hay mucha diferencia entre:

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

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

Donde realmente brilla Git es en la ramificación y el trabajo con otras personas.

Charla técnica de Google:Linus Torvalds en git

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

La página de comparación de Git Wiki

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

Bueno, está distribuido.Los puntos de referencia indican que es considerablemente más rápido (dada su naturaleza distribuida, las operaciones como diferencias y registros son todas locales, por lo que, por supuesto, es increíblemente más rápido en este caso), y las carpetas de trabajo son más pequeñas (lo que todavía me deja boquiabierto).

Cuando trabajas en Subversion, o cualquier otro sistema de control de revisiones cliente/servidor, básicamente creas copias de trabajo en tu máquina el registro de salida revisiones.Esto representa una instantánea en el tiempo de cómo se ve el repositorio.Actualiza su copia de trabajo mediante actualizaciones y actualiza el repositorio mediante confirmaciones.

Con un control de versiones distribuido, no tienes una instantánea, sino todo el código base.¿Quieres hacer una diferencia con una versión de hace 3 meses?No hay problema, la versión anterior de 3 meses todavía está en tu computadora.Esto no sólo significa que las cosas son mucho más rápidas, sino que si estás desconectado de tu servidor central, aún puedes realizar muchas de las operaciones a las que estás acostumbrado.En otras palabras, no sólo tienes una instantánea de una revisión determinada, sino todo el código base.

Uno pensaría que Git ocuparía mucho espacio en su disco duro, pero según un par de puntos de referencia que he visto, en realidad ocupa menos.No me preguntes cómo.Quiero decir, fue construido por Linus, supongo que sabe un par de cosas sobre sistemas de archivos.

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

Puedes cometer cosas rotas.No importa porque otras personas no los verán hasta que los publiques.El tiempo de publicación es diferente al tiempo de confirmación.
Debido a esto, puedes comprometerte con más frecuencia.
Puede fusionar funcionalidades completas.Esta funcionalidad tendrá su propia rama.Todas las confirmaciones de esta rama estarán relacionadas con esta funcionalidad.Puede hacerlo con un CVCS, pero con DVCS es el valor predeterminado.
Puede buscar en su historial (encontrar cuándo cambió una función)
Puedes deshacer una extracción si alguien arruina el repositorio principal, no es necesario corregir los errores.Simplemente borre la combinación.
Cuando necesite un control de fuente en cualquier directorio, haga:iniciar git.y puedes confirmar, deshacer cambios, etc...
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.

Lo curioso es:Alojo proyectos en Subversion Repos, pero accedo a ellos mediante el comando Git Clone.

Por favor lee Desarrollar con Git en un proyecto de código de Google

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

Usar Git en un repositorio Svn me brinda beneficios:

puedo trabajar repartido en varias máquinas, cometiendo y tirando de ellas
tengo un central backup/public repositorio svn para que otros puedan consultarlo
Y son libres de usar Git por su cuenta.

Todas las respuestas aquí son las esperadas y están centradas en el programador; sin embargo, ¿qué sucede si su empresa utiliza control de revisión fuera del código fuente?Hay muchos documentos que no son código fuente que se benefician del control de versiones y deberían estar 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 eso en mente, compare la facilidad de uso, tanto en herramientas como en capacitación del cliente, entre Subversion y git.No puedo ver un escenario donde cualquier El sistema de control de revisiones distribuido será más fácil de usar o explicar a alguien que no sea programador.Me encantaría que me demuestren que estoy equivocado, porque entonces podría evaluar git y tener la esperanza de que sea aceptado por personas que necesitan control de versiones y que no son programadores.

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

Descargo de responsabilidad:Me interesé en Subversion desde el principio (alrededor de la versión 0.29), así que obviamente soy parcial, pero las empresas para las que he trabajado desde entonces se están beneficiando de mi entusiasmo porque he alentado y apoyado su uso.Sospecho que esto es lo que sucede con la mayoría de las empresas de software.Con tantos programadores subiéndose al tren de git, me pregunto cuántas empresas se perderán los beneficios de utilizar 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 (unificada) del seguimiento de problemas, al tiempo que aumenta los requisitos de mantenimiento, hardware y capacitación.

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

Una de las cosas que me molesta de SubVersion es que coloca su propia carpeta en cada directorio de un proyecto, mientras que git solo coloca una en el directorio raíz.Que no es eso Es un gran problema, pero pequeñas cosas como esa se suman.

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

Blog de David Richards WANdisco sobre Subversión / GIT

El surgimiento de GIT ha traído consigo una raza de fundamentalistas del DVCS –los “Gitterons”– que piensan que cualquier cosa que no sea GIT es una mierda.Los Gitteron parecen pensar que la ingeniería de software ocurre en su propia isla y a menudo olvidan que la mayoría de las organizaciones no emplean exclusivamente ingenieros de software senior.Está bien, pero no es así como piensa el resto del mercado, y estoy feliz de demostrarlo:GIT, según el último análisis, tenía menos del tres por ciento del mercado, mientras que Subversion tiene alrededor de cinco millones de usuarios y aproximadamente la mitad del mercado total.

El problema que vimos fue que los Gitterons estaban disparando tiros (bajos) a Subversion.Tweets como “Subversion es tan [lenta/horrible/restrictiva/no huele bien/me mira de manera divertida] y ahora tengo GIT y [todo funciona en mi vida/mi esposa quedó embarazada/tengo novia después 30 años intentándolo / gané seis veces seguidas en la mesa de blackjack].Te dan la imagen.

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

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

Si estoy desarrollando un solo proyecto en mi PC/portátil, git es mejor, porque es mucho más fácil de configurar y usar.No necesita un servidor y no necesita seguir escribiendo las URL del repositorio cuando realiza fusiones.

Si fueran solo 2 personas, diría que git también es más fácil, porque pueden empujarse y tirarse entre sí.

Sin embargo, una vez que superes eso, optaría por la subversión, porque en ese punto necesitas configurar un servidor o una ubicación "dedicados".

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

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

Git fácil tiene una buena página que compara el uso real de Git y SVN lo 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 contenedor liviano encima de Git).

Git y DVCS en general son excelentes para los desarrolladores que codifican mucho de forma independiente porque cada uno tiene su propia rama.Sin embargo, si necesita un cambio de otra persona, ella debe comprometerse con su repositorio local y luego debe enviarle ese conjunto de cambios o usted debe quitárselo a ella.

Mi propio razonamiento también me hace pensar que DVCS dificulta las cosas para el control de calidad y la gestión de versiones si se hacen cosas como versiones centralizadas.Alguien tiene que ser responsable de hacer ese push/pull desde el repositorio de todos los demás, resolver cualquier conflicto que se hubiera resuelto antes en el momento de la confirmación inicial, luego hacer la compilación y luego hacer que todos los demás desarrolladores vuelvan a sincronizar sus repositorios.

Todo esto se puede abordar con procesos humanos, por supuesto;DVCS acaba de romper algo que fue arreglado por el control de versiones centralizado para brindar algunas comodidades nuevas.

Me gusta Git porque en realidad ayuda a la comunicación entre desarrolladores en un equipo mediano a grande.Como sistema de control de versiones distribuido, a través de su sistema push/pull, ayuda a los desarrolladores a crear un ecosistema de código fuente que ayuda a gestionar un gran grupo de desarrolladores que trabajan en un solo proyecto.

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

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

Algunas respuestas han aludido a estos, pero quiero dejar explícitos dos puntos:

1) La capacidad de realizar 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 tanto, irrevocable.Esto limita en gran medida la capacidad del desarrollador de "comprometerse temprano y con frecuencia".

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

Creo que Subversion está bien...hasta que empieces a fusionarte..o hacer algo complicado..o hacer cualquier cosa que Subversion considere complicada (como hacer consultas para averiguar qué ramas alteraron un archivo en particular, dónde se realizó un cambio). de hecho proviene, detectar copiar y pegar, etc)...

No estoy de acuerdo con la respuesta ganadora, diciendo que beneficio principal de GIT es trabajo sin conexión; ciertamente es útil, pero es más como un extra para mi caso de uso.SVK también puede funcionar sin conexión, aunque no tengo ninguna duda en cuál invertir mi tiempo de aprendizaje).

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

Para obtener más detalles sobre una historia fusionada, consulte esto:¿Usar git-svn (o similar) *solo* para ayudar con una fusión de svn?

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

Me encanta poder administrar ramas locales de mi código fuente en Git sin enturbiar el repositorio central.En muchos casos, extraigo el código del servidor Subversion y ejecuto un repositorio Git local sólo para poder hacer esto.También es genial que inicializar un repositorio Git no contamine el sistema de archivos con un montón de molestas carpetas .svn por todas partes.

Y en cuanto a la compatibilidad con herramientas de Windows, TortoiseGit maneja muy bien los conceptos básicos, pero sigo prefiriendo la línea de comandos a menos que quiera ver el registro.Realmente me gusta la forma en que Tortoise{Git|SVN} ayuda a leer los registros de confirmación.

Esta es la pregunta equivocada.Es muy fácil centrarse en los defectos de git y formular un argumento sobre 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 conjunto de construcción de control de versiones de bajo nivel y tiene una interfaz barroca orientada al desarrollador de Linux hace que sea más fácil para las guerras santas ganar tracción y legitimidad percibida.Los defensores de Git golpean el tambor con millones de ventajas en el flujo de trabajo, que los chicos de svn consideran innecesarios.Muy pronto todo el debate se plantea como centralizado versus distribuido, lo que sirve a los intereses de la comunidad de herramientas svn empresariales.Estas empresas, que normalmente publican los artículos más convincentes sobre la superioridad de la subversión en la empresa, dependen de la inseguridad percibida de git y de la preparación empresarial 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ónico.

Mientras que puedes tomar git y construir un reemplazo de subversión centralizado con bastante facilidad, a pesar de haber existido durante más del doble de tiempo, svn nunca ha podido lograr que ni siquiera el seguimiento de fusión básico funcione tan bien como lo hace en git.Una razón básica para esto es la decisión de diseño de hacer que las ramas sean lo mismo que los directorios.No sé por qué tomaron este camino originalmente, ciertamente hace que los pagos parciales sean muy simples.Lamentablemente, también hace que sea imposible realizar un seguimiento adecuado del historial.Ahora, obviamente, se supone que debes usar las convenciones de diseño del repositorio de Subversion para separar las ramas de los directorios normales, y svn usa algunas heurísticas para que las cosas funcionen en los casos de uso diario.Pero todo esto no es más que disimular una decisión de diseño de bajo nivel muy deficiente y limitante.Ser capaz de hacer una diferenciación a nivel de repositorio (en lugar de una diferenciación a nivel de directorio) es una funcionalidad básica y crítica para un sistema de control de versiones, y simplifica enormemente los aspectos internos, haciendo posible construir características más inteligentes y útiles sobre ella.Se puede ver en la cantidad de esfuerzo que se ha puesto en extender la subversión y, sin embargo, lo lejos que está de la cosecha actual de VCS modernos en términos de operaciones fundamentales como la resolución de fusiones.

Ahora aquí está mi consejo más sincero y agnóstico para cualquiera que todavía crea que Subversion es lo suficientemente bueno en el futuro previsible:

Subversion nunca alcanzará a las nuevas generaciones de VCS que han aprendido de los errores de RCS y CVS;Es una imposibilidad técnica a menos que reorganicen el modelo del repositorio desde cero, pero entonces no sería realmente svn, ¿verdad?Independientemente de cuánto crea que no conoce las capacidades de un VCS moderno, su ignorancia no lo protegerá de los peligros de Subversion, muchas de las cuales son situaciones que son imposibles o fáciles de resolver en otros sistemas.

Es extremadamente raro que la inferioridad técnica de una solución sea tan clara como lo es con svn, ciertamente nunca daría esa opinión sobre win-vs-linux o emacs-vs-vi, pero en este caso es así. claro, y el control de fuente es una herramienta tan fundamental en el arsenal del desarrollador, que creo que debe afirmarse de manera inequívoca.Independientemente del requisito de utilizar svn por razones organizativas, imploro a todos los usuarios de svn que no permitan que su mente lógica construya una creencia falsa de que los VCS más modernos sólo son útiles para grandes proyectos de código abierto.Independientemente de la naturaleza de su trabajo de desarrollo, si es programador, será un programador más eficaz si aprende a utilizar VCS mejor diseñados, ya sea Git, Mercurial, Darcs o muchos otros.

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

Con Git obtienes un VCS más flexible.Puede usarlo de la misma manera que SVN con un repositorio remoto donde confirma todos los cambios.Pero también puede usarlo principalmente sin conexión 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.La primera vez me encontré comprometiéndome con ramas equivocadas, creando ramas indirectamente o recibiendo mensajes de error con poca información sobre el error y donde debo buscar en Google para obtener mejor información.Algunas cosas sencillas como la sustitución de marcadores ($Id$) no funcionan, pero GIT tiene un mecanismo de filtrado y enlace muy flexible para fusionar scripts propios y así obtener todo lo que necesita y más, pero necesita más tiempo y lectura de la documentación. ;)

Si trabaja principalmente sin conexión con su repositorio local, no tendrá copia de seguridad si se pierde algo en su máquina local.Con SVN estás trabajando principalmente con un repositorio remoto que también es al mismo tiempo tu copia de seguridad en otro servidor...Git puede funcionar de la misma manera, pero el objetivo principal de Linus no era tener algo como SVN2.Fue diseñado para los desarrolladores del kernel de Linux y las necesidades de un sistema de control de versiones distribuido.

¿Git es mejor que SVN?Los desarrolladores que sólo necesitan algo de historial de versiones y un mecanismo de copia de seguridad tienen una vida buena y fácil con SVN.Los desarrolladores que trabajan a menudo con sucursales, prueban más versiones al mismo tiempo o trabajan principalmente sin conexión pueden beneficiarse de las funciones de Git.Hay algunas características muy útiles, como el almacenamiento oculto que no se encuentra con SVN, que pueden hacer la vida más fácil.Pero, por otro lado, no todas las personas necesitarán todas las funciones.Entonces no puedo ver los muertos de SVN.

Git necesita mejor documentación y el informe de errores debe ser más útil.Además, las GUI útiles existentes sólo se encuentran en raras ocasiones.Esta vez solo encontré 1 GUI para Linux compatible con la mayoría de las funciones de Git (git-cola).La integración de Eclipse está funcionando, pero no se ha lanzado oficialmente y no hay un sitio de actualización oficial (solo algún sitio de actualización externo con compilaciones periódicas desde el tronco). http://www.jgit.org/updates) Entonces, la forma más preferida de usar GIT este día es la línea de comando.

Eric fregadero de SourceGear escribió una serie de artículos sobre las diferencias entre los sistemas de control de versiones distribuidos y no distribuidos.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:

Para las personas que buscan una buena GUI de Git, Syntevo SmartGit podría ser una buena solución.Es propietario, pero gratuito para uso no comercial, se ejecuta en Windows/Mac/Linux e incluso admite SVN usando algún tipo de puente git-svn, creo.

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

Creo que es bastante seguro decir que entre los desarrolladores, SVN Vs.La discusión sobre Git ha estado furiosa desde hace algún tiempo, y cada uno tiene su propia opinión sobre cuál es mejor.Esto incluso se mencionó en las preguntas durante nuestro seminario web sobre Subversión en 2010 y más allá.

Hyrum Wright, nuestro director de código abierto y presidente de Subversion Corporation, habla sobre las diferencias entre Subversion y Git, junto con otros sistemas de control de versiones distribuidas (DVCS).

También habla sobre los próximos cambios en Subversion, como Working Copy Next Generation (WC-NG), que cree que hará que varios usuarios de Git vuelvan a convertirse a Subversion.

Mire su video y háganos saber lo que piensa, ya sea comentando en este blog o publicando en nuestros foros.¡El registro es sencillo y sólo te llevará un momento!

Git en Windows ahora tiene bastante soporte.

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

y el manual para una mejor experiencia con Windows Git.

He estado viviendo en Git Land últimamente, y me gusta para proyectos personales, pero todavía no podría cambiar los proyectos de trabajo desde Subversion dado el cambio en la forma de pensar que se requiere por parte del personal, sin ningún beneficio apremiante.Además, el mayor proyecto que ejecutamos internamente depende en gran medida de svn: externos que, por lo que he visto hasta ahora, no funciona tan bien y sin problemas en Git.

En primer lugar, el control de versiones concurrentes parece un problema fácil de resolver.No lo es en absoluto.De todos modos...

SVN es bastante poco intuitivo.Git es aún peor.[especulación sarcástica] Esto podría deberse a que los desarrolladores, a quienes les gustan los problemas difíciles como el control de versiones concurrentes, no tienen mucho interés en crear una buena interfaz de usuario.[/especulación-sarcástica]

Los partidarios de SVN creen que no necesitan un sistema de control de versiones distribuido. Yo también pensé eso. Pero ahora que usamos Git exclusivamente, lo creo.Ahora el control de versiones funciona para mí Y para el equipo/proyecto en lugar de simplemente trabajar para el proyecto.Cuando necesito una sucursal, la hago.A 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 interfaz de usuario que es un sistema de control de versiones moderno).

Por qué creo que Subversion es mejor que Git (al menos para los proyectos en los que trabajo), principalmente debido a su usabilidad y flujo de trabajo más simple:

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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow