subversion - tortoise svn




¿Por qué Git es mejor que Subversion? (20)

He estado usando Subversion por 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 número creciente de desarrolladores que afirman que Subversion tiene problemas y que deberíamos estar cambiando a la nueva generación de sistemas de control de versiones distribuidos, como Git .

¿Cómo mejora Git en Subversion?


Últimamente he estado viviendo en Git land, y me gusta para proyectos personales, pero no sería capaz de cambiar los proyectos de trabajo desde Subversion, dado el cambio en el pensamiento del personal requerido, sin ningún beneficio urgente. Además, el proyecto más grande que ejecutamos internamente es extremadamente dependiente de svn:externals que, por lo que he visto hasta ahora, no funciona tan bien y sin problemas en Git.




Primero, el control de versiones concurrentes parece ser un problema fácil de resolver. No es en absoluto. De todas formas...

SVN es bastante no intuitivo. Git es aún peor. [especulación sarcástica] Esto podría deberse a que los desarrolladores, a los que les gustan 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 piensan que no necesitan un sistema de control de versiones distribuido. Yo también lo pensé. 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. 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 falta de UI arcana y absurda que es un sistema de control de versiones moderno).


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

1) La capacidad de realizar confirmaciones selectivas (por ejemplo, git add --patch ). Si su directorio de trabajo contiene varios cambios que no son parte del mismo cambio lógico, Git hace que sea muy fácil realizar un compromiso 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 compromiso es inmediatamente público, y por lo tanto irrevocable. Esto limita enormemente la capacidad del desarrollador para "cometer temprano, cometer a menudo".

Git es más que un VCS; También es una herramienta para desarrollar parches. La subversión es simplemente un VCS.


Bueno, se distribuye. Los puntos de referencia indican que es considerablemente más rápido (dada su naturaleza distribuida, las operaciones como diffs y los registros son locales, por lo que es increíblemente más rápido en este caso), y las carpetas de trabajo son más pequeñas (lo que aún me sorprende).

Cuando está trabajando en Subversion, o en cualquier otro sistema de control de revisión de cliente / servidor, esencialmente crea copias de trabajo en su máquina al revisar las revisiones. Esto representa una instantánea en el tiempo de cómo se ve el repositorio. Actualiza su copia de trabajo a través de actualizaciones, y actualiza el repositorio a través de confirmaciones.

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

Pensarías 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 toma menos. No me preguntes cómo. Quiero decir, fue construido por Linus, él sabe una o dos cosas sobre sistemas de archivos, supongo.


Creo que Subversion está bien ... hasta que empieces a fusionar ... o hacer algo complicado ... o hacer algo que Subversion cree que es complicado (como hacer consultas para descubrir qué ramas se han desordenado con un archivo en particular, de dónde proviene un cambio, detectar copias y pegar) , etc) ...

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

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

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


Esta es la pregunta incorrecta que se debe hacer. Es muy fácil concentrarse en las verrugas de Git y formular un argumento acerca de por qué la subversión es ostensiblemente mejor, al menos en algunos casos de uso. El hecho de que git se diseñó originalmente como un conjunto de construcción de control de versiones de bajo nivel y tiene una interfaz orientada a desarrolladores de linux barroco facilita que las guerras santas ganen fuerza y ​​perciban la legitimidad. Los defensores de Git golpean el tambor con millones de ventajas de flujo de trabajo, que svn chicos proclaman innecesarias. Muy pronto, todo el debate se enmarca como centralizado frente a distribuido, lo que sirve a los intereses de la comunidad de herramientas svn empresariales. Estas compañías, que normalmente publican los artículos más convincentes sobre la superioridad de Subversion 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 puede tomar git y construir un reemplazo de subversión centralizado con bastante facilidad, a pesar de estar presente por más del doble de tiempo, svn nunca ha sido capaz de hacer que el seguimiento de fusión básico funcione en cualquier lugar tan cerca como lo hace en git. Una razón básica de esto es la decisión de diseño de hacer que las sucursales sean lo mismo que los directorios. Originalmente, no sé por qué se fueron de esta manera, ciertamente hace que los registros parciales sean muy simples. Desafortunadamente, también hace imposible rastrear la historia correctamente. Ahora, obviamente, se supone que debe usar las convenciones de diseño del repositorio de subversión para separar las sucursales de los directorios regulares, y svn utiliza algunas heurísticas para hacer que las cosas funcionen en los casos de uso diario. Pero todo esto es solo un papeleo sobre una decisión de diseño muy pobre y limitante de bajo nivel. Ser capaz de hacer una diferencia en el repositorio (en lugar de una diferencia en el directorio) es una funcionalidad básica y crítica para un sistema de control de versiones, y simplifica enormemente las funciones internas, haciendo posible la creación de funciones más inteligentes y útiles sobre ella. Puede ver la cantidad de esfuerzo que se ha invertido en extender la subversión y, sin embargo, a qué distancia está de la cosecha actual de VCS modernos en términos de operaciones fundamentales como la resolución de fusión.

Este es mi consejo sincero y agnóstico para cualquiera que aún crea que Subversion es lo suficientemente bueno para el futuro inmediato:

Subversion nunca alcanzará a las nuevas razas de VCS que han aprendido de los errores de RCS y CVS; es una imposibilidad técnica a menos que actualicen el modelo de repositorio desde el principio, pero en realidad no sería svn ¿verdad? Independientemente de cuánto piense que no tiene las capacidades de un VCS moderno, su ignorancia no lo protegerá de los escollos de Subversion, muchos de los cuales son situaciones 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 con svn, ciertamente nunca diré tal opinión sobre win-vs-linux o emacs-vs-vi, pero en este caso es así Es claro, y el control de la fuente es una herramienta tan fundamental en el arsenal del desarrollador, que creo que debe ser declarado de manera inequívoca. Independientemente del requisito de usar svn por razones organizativas, imploro a todos los usuarios de svn que no permitan que su mente lógica cree que los VCS más modernos solo son útiles para grandes proyectos de código abierto. Independientemente de la naturaleza de su trabajo de desarrollo, si usted es un programador, será un programador más efectivo si aprende a usar VCS mejor diseñados, ya sea Git, Mercurial, Darcs o muchos otros.


Git también hace que la ramificación y la fusión sean realmente fáciles. Subversion 1.5 acaba de agregar el seguimiento de fusión, pero Git sigue siendo mejor. Con Git se ramifica es muy rápido y barato. Hace que la creación de una rama para cada nueva característica sea más factible. Los repositorios Oh y Git son muy eficientes con espacio de almacenamiento en comparación con Subversion.


Git y DVCS en general son geniales para los desarrolladores que hacen mucha codificación independientemente unos de otros porque cada uno tiene su propia rama. Sin embargo, si necesita un cambio de otra persona, ella tiene que comprometerse con su representante local y luego debe enviar ese cambio a usted o usted debe retirárselo.

Mi propio razonamiento también me hace pensar que DVCS hace las cosas más difíciles para el control de calidad y la administració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 momento de la confirmación inicial antes, luego hacer la compilación y luego hacer que todos los otros 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 proporcionar algunas nuevas comodidades.


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 las conexiones SSH). La bifurcación es mucho más fácil (un simple comando para bifurcar, un simple comando para fusionar)


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

Por favor, lea Desarrollar con Git en un proyecto de Google Code

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

Usar Git en un repositorio de Svn me da beneficios:

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

Me encanta poder administrar las sucursales locales de mi código fuente en Git sin enturbiar el agua del depósito central. En muchos casos, extraeré el código del servidor de Subversion y ejecutaré un repositorio Git local para poder hacer esto. También es genial que la inicialización de un repositorio Git no contamine el sistema de archivos con un montón de carpetas .svn molestas en todas partes.

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


Me gusta Git porque en realidad ayuda a los desarrolladores de comunicación a desarrollar en un equipo mediano a grande. Como un 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 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í.


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 se fusionan.

Si solo fueran 2 personas, diría que git también es más fácil, porque puedes empujar y tirar de los demás.

Sin embargo, una vez que llegue más allá de eso, me gustaría subversión, porque en ese momento necesita configurar un servidor o ubicación "dedicada".

Puede hacer esto igual de bien con git que 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, luego git push. El paso adicional se vuelve molesto simplemente porque terminas haciéndolo mucho.

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


Subversion es muy facil de usar. Nunca he encontrado en los últimos años un problema o que algo no funcione 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. Puede usarlo de la misma manera que SVN con un repositorio remoto donde confirma todos los cambios. Pero también puede usarlo casi 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. Me encontré por primera vez comprometiéndome con sucursales equivocadas, creando sucursales indirectamente o recibiendo mensajes de error con poca información sobre el error y dónde debo buscar con Google para obtener mejores informaciones. Algunas cosas sencillas, como la sustitución de marcadores ($ Id $), no funcionan, pero GIT tiene un mecanismo de enganche y filtrado muy flexible para fusionar sus propios scripts y así obtener todas las cosas que necesita y más, pero necesita más tiempo y lectura de la documentación. ;)

Si trabaja casi sin conexión con su repositorio local, no tendrá una copia de seguridad si algo se pierde en su máquina local. Con SVN, la mayoría de las veces trabaja con un repositorio remoto que también es la misma vez que la 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 distribuido.

¿Es Git mejor que SVN? Los desarrolladores que necesitan solo un 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, que prueban más versiones al mismo tiempo o que trabajan casi sin conexión pueden beneficiarse de las características de Git. Existen algunas funciones muy útiles, como el ocultamiento que no se encuentra con SVN, que pueden hacer la vida más fácil. Pero en el otro lado no todas las personas necesitarán todas las características. Así que no puedo ver a los muertos de SVN.

Git necesita una mejor documentación y el informe de errores debe ser más útil. También las GUI útiles existentes son raramente. Esta vez solo he encontrado 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 un sitio de actualización externo con compilaciones periódicas desde el troncal http://www.jgit.org/updates ). Así que la forma más preferida de usar Git en estos días. es la linea de comando


Todas las respuestas aquí son las esperadas, centradas en el programador; sin embargo, ¿qué sucede si su empresa utiliza el 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 que deben 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.

Teniendo eso en cuenta, compare la facilidad de uso, tanto en las herramientas del cliente como en la capacitación, entre Subversion y git. No puedo ver un escenario en el que cualquier sistema de control de revisión distribuido sea más fácil de usar o explicar a un no programador. Me encantaría estar equivocado, porque entonces sería capaz de evaluar git y, de hecho, tener la esperanza de que lo acepten personas que necesitan un control de versiones que no son programadores.

Incluso entonces, si la administración me pregunta por qué deberíamos pasar de un sistema de control de revisión centralizado a uno distribuido, me sería muy difícil dar una respuesta honesta, porque no la necesitamos.

Descargo de responsabilidad: Me interesé en Subversion desde el principio (alrededor de v0.29), por lo que obviamente soy parcial, pero las empresas en 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 ocurre con la mayoría de las compañías de software. Con tantos programadores que se suben al carro de git, me pregunto cuántas empresas se van a perder los beneficios de usar el control de versiones fuera del código fuente. Incluso si tiene sistemas separados para diferentes equipos, está perdiendo algunos de los beneficios, como la integración de seguimiento de problemas (unificados), al tiempo que aumenta los requisitos de mantenimiento, hardware y capacitación.


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

Por supuesto, SubVersion tiene tortuga, lo cual es [generalmente] muy bueno.


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

Creo que es bastante seguro decir que entre los desarrolladores, el SVN vs. El argumento de Git se ha estado librando desde hace algún tiempo, y cada uno tiene su propio punto de vista sobre cuál es mejor. Esto incluso se mencionó en las preguntas durante nuestro seminario web sobre Subversion en 2010 y más allá.

Hyrum Wright, nuestro Director de Código Abierto y el 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 convertir a Subversion.

Mire su video y háganos saber lo que piensa comentando en este blog o publicando en nuestros foros. El registro es simple y solo tomará un momento!


Eric Sink 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 :







git