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 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 en Subversion?
Respuestas:
Git no es mejor que Subversion. Pero tampoco es peor. Es diferente.
La diferencia clave es que está descentralizada. Imagine que es un desarrollador en el camino, desarrolla en su computadora portátil y desea tener el control de fuente para poder retroceder 3 horas.
Con Subversion, 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, literalmente debe copiarlo / 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 recupera la conectividad con el repositorio principal, puede comprometerse contra él.
Esto se ve bien al principio, pero solo tenga en cuenta la complejidad adicional de este enfoque.
Git parece ser la cosa "nueva, brillante, genial". De ninguna manera es 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 de "Control de fuente distribuida" solo porque es nuevo y está escrito por Linus Torvalds, sin realmente sabiendo por qué / si es mejor.
Subversion tiene problemas, pero también Git, Mercurial, CVS, TFS o lo que sea.
Editar: Entonces, esta respuesta ahora tiene un año y todavía genera muchos votos a favor, por lo que pensé 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 ser realmente confuso al principio cuando se trabaja descentralizado. ¿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 --compartido, lo que parece ser la forma "adecuada" 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: 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 en el camino, 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 formas de copiar el repositorio). Con Git, ese es el modo predeterminado de todos modos. Sin embargo, es un comando adicional (git commit se compromete localmente, mientras que git push origin master empuja la rama maestra al control remoto llamado "origin").
Como se dijo anteriormente: Git agrega complejidad. Dos modos de crear repositorios, pago versus clonación, confirmación vs. inserción ... Debe 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 todavía uso 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, confirmar y pagar y está listo para comenzar y puede recoger cosas como ramificación, actualización, etc. más adelante en.
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 escuché, el soporte de ramificación y fusión es mucho mejor (lo cual es de esperar, ya que estas son las razones principales por las que fue escrito).
Esto también explica por qué gana tanto revuelo en Internet, ya que Git es perfectamente adecuado para proyectos de código abierto: simplemente bifurca, confirma tus cambios en tu propia bifurcación y luego pide al encargado del proyecto original que extraiga tus cambios. Con Git, esto simplemente funciona. Realmente, 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 empuja sus cambios a SVN.
Pero incluso con esta larga adición, aún mantengo mi mensaje central: Git no es mejor ni peor, es simplemente diferente. Si tiene la necesidad de "Control de fuente fuera de línea" y la voluntad de pasar un tiempo extra aprendiéndolo, es fantástico. Pero si tiene un control de origen estrictamente centralizado y / o tiene dificultades para introducir el control de origen 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.
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, puede tener su propio repositorio en línea y publicar "solicitudes push" para sus parches. Todos los que quieran sus parches pueden incluirlos en su proyecto, incluidos los encargados de mantenimiento 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 escala 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 el flujo de trabajo que desee y Git lo admitirá.
Finalmente, está GitHub , un gran sitio para alojar sus repositorios Git.
Inconvenientes de Git:
Otras respuestas han hecho un buen trabajo al explicar las características principales de Git (que son geniales). Pero también hay tantas pequeñas formas en que Git se comporta mejor y ayuda a mantener mi vida más sana. Estas son algunas de las pequeñas cosas:
git mvy git rm.
" Por qué Git es mejor que X " describe los diversos pros y contras de Git frente a otros SCM.
Brevemente:
Hay algunas desventajas:
En el uso más simplista, Subversion y Git son más o menos 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 Git realmente brilla es ramificarse y trabajar con otras personas.
Google Tech Talk: Linus Torvalds en git
http://www.youtube.com/watch?v=4XpnKHJAok8
La página de comparación de Git Wiki
Bueno, está distribuido. Los puntos de referencia indican que es considerablemente más rápido (dada su naturaleza distribuida, las operaciones como diffs y logs 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 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 del aspecto del repositorio. Actualiza su copia de trabajo mediante actualizaciones, y actualiza el repositorio mediante confirmaciones.
Con un control de versión distribuido, no tiene una instantánea, sino toda la base de código. ¿Quieres hacer un diff 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, 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 toda la base de código.
Se podría pensar que Git ocuparía un montón de espacio en su disco duro, pero desde un par de puntos de referencia que he visto, en realidad toma menos. No me preguntes cómo. Quiero decir, fue construido por Linus, creo que sabe una o dos cosas sobre los sistemas de archivos.
Los puntos principales que me gustan de DVCS son aquellos:
La razón principal de un proyecto relativamente grande es la comunicación mejorada creada por el punto 3. Otros son bonificaciones bonitas.
Lo curioso es: alojo proyectos en Subversion Repos, pero accedo a ellos a través del comando Git Clone.
Lea Desarrollar con Git en un proyecto de código de Google
Aunque Google Code habla Subversion de forma nativa, puede usar Git fácilmente durante el desarrollo. La búsqueda de "git svn" sugiere que esta práctica está muy extendida, y nosotros también lo alentamos a que experimente con ella.
Usar Git en un repositorio Svn me da beneficios:
backup/public para que otros puedan verTodas 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 deberían 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 eso en mente, compare la facilidad de uso, tanto en herramientas como capacitación del cliente, 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 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 que no son programadores.
Incluso entonces, si la gerencia me pregunta por qué deberíamos pasar de un sistema de control de revisión centralizado a uno distribuido, sería difícil dar una respuesta honesta, porque no la necesitamos.
Descargo de responsabilidad: Me interesé en Subversion desde el principio (alrededor de v0.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 así es como sucede con la mayoría de las compañías de software. Con tantos programadores subiéndose al tren de git, me pregunto cuántas empresas 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 (unificada) de 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 Michael : Git no es mejor ni peor que Subversion, es diferente.
Una de las cosas de 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 que la gran cosa, pero pequeñas cosas como que se suman.
Por supuesto, SubVersion tiene Tortoise, que es [generalmente] muy agradable.
Blog de David Richards WANdisco sobre Subversion / GIT
La aparición de GIT ha traído consigo una raza de fundamentalistas de DVCS, los 'Gitterons', que piensan que cualquier cosa que no sea GIT es una mierda. Los Gitterons 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. Eso está bien, pero no es lo que piensa el resto del mercado, y estoy feliz de demostrarlo: GIT, en el último vistazo tenía menos del tres por ciento del mercado, mientras que Subversion tiene en la región de cinco millones de usuarios y aproximadamente la mitad de El mercado general.
El problema que vimos fue que los Gitterons estaban disparando (baratos) a Subversion. Tweets como "Subversion es tan [lento / horrible / restrictivo / no huele bien / me mira de manera divertida] y ahora tengo GIT y [todo funciona en mi vida / mi esposa quedó embarazada / tuve una novia después 30 años de intentos / gané seis veces corriendo 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 el seguimiento de fusión, pero Git sigue siendo mejor. Con Git la ramificación es muy rápida y barata. 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 el espacio de almacenamiento en comparación con Subversion.
Se trata de la facilidad de uso / pasos necesarios para hacer algo.
Si estoy desarrollando un solo proyecto en mi PC / computadora 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 hace fusiones.
Si solo fueran 2 personas, diría que git también es más fácil, porque solo pueden empujar y tirar unos de otros.
Sin embargo, una vez que vaya más allá de eso, optaría por la subversión, porque en ese punto debe configurar un servidor o ubicación 'dedicado'.
Puede hacer esto tan bien con git como con SVN, pero los beneficios de git se ven compensados por la necesidad de realizar pasos adicionales para sincronizar con un servidor central. En SVN solo te comprometes. En git tienes que git commit, luego git push. El paso adicional se vuelve molesto simplemente porque terminas haciéndolo demasiado.
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 a largo plazo.
Git y DVCS en general son excelentes para los desarrolladores que realizan una gran cantidad de codificación independientemente uno del otro porque cada uno tiene su propia rama. Sin embargo, si necesita un cambio de otra persona, ella tiene que comprometerse con su repositorio local y luego debe empujar ese conjunto de cambios hacia usted o usted debe quitá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 versiones si haces cosas como versiones centralizadas. Alguien tiene que ser responsable de hacer ese push / pull desde el repositorio de todos los demás, resolver los conflictos que se habrían resuelto en el momento de la confirmación inicial antes, luego hacer la compilación y luego hacer que todos los demás desarrolladores vuelvan a sincronizar sus repositorios.
Todo esto puede abordarse con procesos humanos, por supuesto; DVCS acaba de romper algo que fue corregido por el control de versiones centralizado para proporcionar algunas nuevas comodidades.
Me gusta Git porque realmente ayuda a los desarrolladores de comunicación a desarrolladores en un equipo de 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 administrar un gran grupo de desarrolladores que trabajan en un solo proyecto.
Por ejemplo, digamos 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 los 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, hay otros beneficios que se mencionan en otras respuestas aquí.
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 múltiples cambios que no son 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 commit es inmediatamente público y, por lo tanto, irrevocable. Esto limita enormemente la capacidad del desarrollador de "comprometerse temprano, comprometerse con frecuencia".
Git es más que solo un VCS; También es una herramienta para desarrollar parches. Subversion es simplemente un VCS.
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 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 funcionar sin conexión, aún no hay dudas para mí en cuál invertir mi tiempo de aprendizaje
Es solo que es increíblemente potente y rápido y, después de acostumbrarse a los conceptos, es muy útil (sí, en ese sentido: fácil de usar).
Para obtener más detalles sobre una historia de fusión, vea esto: ¿Cómo usar git-svn (o similar) * solo * para ayudar con una fusión de svn?
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 inicializar las conexiones SSH). La ramificación es mucho más fácil (un comando simple para ramificar, un comando simple para fusionar)
Me encanta poder administrar las sucursales locales de mi código fuente en Git sin enturbiar el agua del repositorio central. En muchos casos, verificaré el código del servidor Subversion y ejecutaré un repositorio Git local solo 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 en todas partes.
Y en lo que respecta al soporte de herramientas de Windows, TortoiseGit maneja los conceptos básicos muy bien, pero todavía prefiero la línea de comando a menos que quiera ver el registro. Realmente me gusta la forma en que Tortoise {Git | SVN} ayuda al leer los registros de confirmación.
Esta es la pregunta incorrecta que debe hacerse. Es muy fácil concentrarse en las verrugas de git y formular un argumento sobre por qué la subversión es aparentemente mejor, al menos para 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 barroca orientada al desarrollador de Linux hace que sea más fácil para las guerras santas ganar tracción y percibir legitimidad. Los defensores de Git golpean el tambor con millones de ventajas de flujo de trabajo, que los muchachos proclaman innecesarios. Muy pronto todo el debate se enmarca como centralizado vs distribuido, lo que sirve a los intereses de la comunidad de herramientas empresariales. Estas empresas, que suelen publicar los artículos más convincentes sobre la superioridad de Subversion en la empresa,
Pero aquí está el problema: Subversion 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 lograr que el seguimiento de fusión básico funcione en un lugar tan cercano 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é fueron de esta manera originalmente, ciertamente hace que los pagos parciales sean muy simples. Desafortunadamente, también hace que sea imposible rastrear el historial correctamente. Ahora, obviamente, se supone que debe usar convenciones de diseño de repositorio de subversión para separar las ramas de los directorios normales, y svn usa algunas heurísticas para hacer que las cosas funcionen para los casos de uso diario. Pero todo esto solo está empañando una decisión de diseño de bajo nivel muy pobre y limitante. 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, lo que hace posible construir funciones más inteligentes y útiles. Puede ver la cantidad de esfuerzo que se ha dedicado a extender la subversión y, sin embargo, cuán lejos está de la cosecha actual de VCS modernos en términos de operaciones fundamentales como la resolución de fusión.
Ahora, este es mi consejo sincero y agnóstico para cualquiera que todavía crea que Subversion es lo suficientemente bueno para el futuro previsible:
Subversion nunca alcanzará a las razas más nuevas de VCS que han aprendido de los errores de RCS y CVS; es una imposibilidad técnica a menos que reorganicen el modelo de repositorio desde cero, pero entonces realmente no sería svn, ¿verdad? Independientemente de cuánto creas que no tienes las capacidades de un VCS moderno, tu ignorancia no te protegerá de las trampas de la Subversión, muchas de las 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 lo es con svn, ciertamente nunca diría tal opinión sobre win-vs-linux o emacs-vs-vi, pero en este caso es así claro, y el control de código fuente es una herramienta tan fundamental en el arsenal del desarrollador, que creo que debe declararse inequívocamente. Independientemente del requisito de usar svn por razones organizativas, imploro a todos los usuarios de svn que no dejen que su mente lógica construya una falsa creencia de 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.
Subversion es muy fácil 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 excelentes de GUI 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 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 ramas incorrectas, creando ramas indirectamente u obteniendo mensajes de error con poca información sobre el error y dónde debo buscar con Google para obtener mejores informaciones. Algunas cosas fáciles como la sustitución de marcadores ($ Id $) no funcionan, pero GIT tiene un mecanismo de filtrado y conexión 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 trabaja principalmente fuera de línea con su repositorio local, no tiene respaldo si algo se pierde en su 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 distribuido.
¿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, prueban más versiones al mismo tiempo o trabajan principalmente fuera de línea pueden beneficiarse de las características de Git. Hay algunas características muy útiles como el alijo 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 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 raras. Esta vez solo he encontrado 1 GUI para Linux con soporte para la mayoría de las características 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 algunos sitios de actualización externos con compilaciones periódicas desde el tronco http://www.jgit.org/updates ) Entonces, la forma más preferida de usar Git en estos días Es la línea de comando.
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. Muy interesante lectura.
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. Su propietario, pero gratuito para uso no comercial, se ejecuta en Windows / Mac / Linux e incluso es compatible con 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, el SVN vs. El argumento de Git ha estado furioso durante algún tiempo, y cada uno tiene su propia opinión sobre cuál es mejor. Esto se mencionó incluso en las preguntas durante nuestro seminario web sobre Subversion 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 convertir a Subversion.
Eche un vistazo a su video y cuéntenos su opinión comentando en este blog o publicando en nuestros foros. ¡El registro es simple y solo tomará un momento!
Git en Windows está bastante bien soportado ahora.
Echa un vistazo a GitExtensions = http://code.google.com/p/gitextensions/
y el manual para una mejor experiencia de Windows Git.
Últimamente he estado viviendo en Git Land, y me gusta para proyectos personales, pero aún no podría cambiarme de proyectos de trabajo desde Subversion dado el cambio en la forma de pensar requerida por el personal, sin ningún beneficio urgente. Además, el proyecto más grande que ejecutamos internamente es extremadamente dependiente de svn: externos que, por lo que he visto hasta ahora, no funcionan tan bien y sin problemas en Git.
Primero, el control de versiones concurrentes parece un problema fácil de resolver. No es para nada. 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 quienes les gustan los problemas difíciles como el control de versiones concurrentes, no tienen mucho interés en hacer una buena interfaz de usuario. [/ 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. 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 absurda y arcana 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/