Subversion vs. Git
Cuando se habla de control de versiones, hay dos grandes formas de encarar el tema: centralizado o distribuido.
Durante un año estuve usando Git (un sistema de control de versiones distribuido), y ahora hace un mes y medio que estoy usando Subversion (que es centralizado).
Lo que sigue es un intento de comparar ambas herramientas, desde mi punto de vista personal, sin intención de hacer una comparación exhaustiva ni del todo objetiva.
Lo primero que hay que aclarar es que ni Git es del todo "distribuido" (ya que se suele mantener un repositorio centralizado), ni Subversion es totalmente centralizado (porque se trabaja sobre una copia local). La diferencia en realidad es donde ocurren las operaciones (branch, commit, etc.). En el caso de Git (y los demás que son distribuidos como Mercurial), las operaciones son locales, mientras que en Subversion ocurren en el servidor.
Esto quiere decir que en Git puedo hacer N commits antes de mandar los cambios al servidor, mientras que en Subversion cada commit se hace en el servidor.
Algunas consecuencias de esto son que:
Una de las cosas que no me convencen del todo de Subversion, es que no puedo dejar un cambio por la mitad, para hacer por ejemplo un arreglo en la última versión estable. En Git, aunque tenga cambios pendientes, puedo moverlos a un nuevo branch, arreglar lo que sea que estuviera roto, y volver a poner arriba de eso los cambios que moví temporalmente. En Subversion, la mejor alternativa que encontré a esto, sería hacer un checkout en otro directorio para hacer el arreglo ahí.
Eso nos lleva a otra diferencia: en Git hacer un branch es totalmente natural. De hecho, cada copia local puede verse como un branch. Llevado al extremo, hay quienes hacen un branch para cada nueva feature que van a estar trabajando. En Subversion, un branch se usa solamente para congelar una versión, y no es posible hacerlo de forma local.
Por último, hace unos días apareció esta noticia, que dice que GitHub es el repositorio más popular (para proyectos open source al menos). Puede ser un punto a considerar al momento de elegir.
En conclusión, si me dan a elegir, me quedo con Git. Pero lo verdaderamente importante, sea cual sea la herramienta que se use, es tener algún tipo de manejo de versiones.
Si alguien se quedó con ganas de saber más, acá les dejo una comparación más seria de los dos.
Durante un año estuve usando Git (un sistema de control de versiones distribuido), y ahora hace un mes y medio que estoy usando Subversion (que es centralizado).
Lo que sigue es un intento de comparar ambas herramientas, desde mi punto de vista personal, sin intención de hacer una comparación exhaustiva ni del todo objetiva.
Lo primero que hay que aclarar es que ni Git es del todo "distribuido" (ya que se suele mantener un repositorio centralizado), ni Subversion es totalmente centralizado (porque se trabaja sobre una copia local). La diferencia en realidad es donde ocurren las operaciones (branch, commit, etc.). En el caso de Git (y los demás que son distribuidos como Mercurial), las operaciones son locales, mientras que en Subversion ocurren en el servidor.
Esto quiere decir que en Git puedo hacer N commits antes de mandar los cambios al servidor, mientras que en Subversion cada commit se hace en el servidor.
Algunas consecuencias de esto son que:
- En Subversion los números de cada revisión son consecutivos, mientras que en Git cada commit se identifica con un UUID
- En Git puedo hacer commits intermedios, sin necesidad de tener una versión "estable", porque puedo hacer el push al final. En Subversion, cuando hago un commit tengo que tener una versión consistente antes de hacer el commit para no romper nada que pueda necesitar alguien más. Ese commit puede ser eventualmente bastante grande.
Una de las cosas que no me convencen del todo de Subversion, es que no puedo dejar un cambio por la mitad, para hacer por ejemplo un arreglo en la última versión estable. En Git, aunque tenga cambios pendientes, puedo moverlos a un nuevo branch, arreglar lo que sea que estuviera roto, y volver a poner arriba de eso los cambios que moví temporalmente. En Subversion, la mejor alternativa que encontré a esto, sería hacer un checkout en otro directorio para hacer el arreglo ahí.
Eso nos lleva a otra diferencia: en Git hacer un branch es totalmente natural. De hecho, cada copia local puede verse como un branch. Llevado al extremo, hay quienes hacen un branch para cada nueva feature que van a estar trabajando. En Subversion, un branch se usa solamente para congelar una versión, y no es posible hacerlo de forma local.
Por último, hace unos días apareció esta noticia, que dice que GitHub es el repositorio más popular (para proyectos open source al menos). Puede ser un punto a considerar al momento de elegir.
En conclusión, si me dan a elegir, me quedo con Git. Pero lo verdaderamente importante, sea cual sea la herramienta que se use, es tener algún tipo de manejo de versiones.
Si alguien se quedó con ganas de saber más, acá les dejo una comparación más seria de los dos.
solo he usado subversion y no apesta tanto, algunos problemas que se des-sincronizo con el server un vez pero posiblemente debido a que soy de madera y no a una "carencia" del producto (como diría Mercedita), pero como decís vos... lo importante es usar algo
ResponderBorrarOjo que yo no digo que Subversion apesta. Está bueno y es muy útil. Lo que digo sí, es que me gusta más Git.
ResponderBorrarbuena opinión Marcos, lo estoy tomando en cuenta cual tipo de palicación de manejo de versiones utilizar.
ResponderBorrarSaludos
Marcos, para dejar un cambio por la mitad lo que hago yo es un patch.
ResponderBorrarCreo el patch con mis cambios, hago revert de las modificaciones y hago el commit el arreglo puntual. Luego aplico el patch que había creado a mi código y así puedo seguir en esa feature que estaba trabajando.
Kozhy: me alegro que sea de utilidad.
ResponderBorrarsebagomez: Gracias por el dato, voy a buscar como se hace :)
ResponderBorrarEl dilema que planteas es mas bien por desconocimiento, los repositorios centralizados (CVS y subversion) estuvieron primero que los repositorios descentralizados (git, mercurial y cia.).
ResponderBorrarPodemos decir que los segundos son una evolución de los primeros, surgieron de la necesidad de un trabajo mas eficiente entre los programadores de proyectos opensource.
Saludos!
Comentas que svn no es posible los branch no es cierto, en realidad los branch y los tag se encuentran el el svn por herencia del cvs, svn en comparación al cvs ha traído que el concepto de branch dejara de tener sentido. Ya no se usan con tanta regularidad como se usarían en cvs. Git esta pensado para un trabajo mas 'independiente' del repo. En las empresas svn es ideal por su carácter centralizado
Borrararmindux: Es verdad que SVN es anterior a Git, pero eso no quiere decir que no se puedan comparar, ni que no se sigan usando ambos.
ResponderBorrarCon respecto a que "es más bien por desconocimiento", también puede ser cierto, ya que no he usado más que las funcionalidades básicas de ambos. Si tenés algún conocimiento más profundo sobre este tema, se valora el aporte...
Para podere comparar los escenarios deben ser los mismos. utiliza SVN por el mismo tiempo, averigua como solucionar los problemas y luego compara. Por que cada uno tiene un concepto diferente, para un uso y un escenario, es como comparar un sedan contra una moto, si comparas GIT con Mercuarial las cosas serian diferente ahi si comparas sedan contra sedan.
ResponderBorrarNo estoy de acuerdo... Los dos sirven básicamente para lo mismo: tener la historia de cambios de un repositorio. La forma en la que resuelven el problema sí es distinta, y ahí es que tiene sentido la comparación.
BorrarSi fuera necesario el mismo tiempo para probar algo antes de formarse una opinión y elegir, nadie podría innovar. Por ejemplo yo llevaba 15 años usando Windows y me bastó con usar Mac una semana para darme cuenta que me gustaba más y cambiarme. Hoy han pasado 4 años desde esa decisión y no me he arrepentido ni un minuto.
BorrarComparar un sedán con una moto es apropiado en ciertos casos, sobre todo si de lo que se habla es de vehículo para transportarse. Creo que Marcos tiene razón al decir que si tiene sentido la comparación dado que los dos se usan en principio para control de versiones.
BorrarGracias Marcos,
ResponderBorrarVoy por Git y RedMine.
Saludos
Nicolás
Hola Marcos, gracias por compartir, no conozco GIT y me intereso tu post sobre las diferencias. Disciento en una cosa: "En Subversion, un branch se usa solamente para congelar una versión", tenes Branches y Tags donde los banches son para nuevos features o correccion de bugs y los Tags son para congelar versiones. Saludos.
ResponderBorrarPablo: Gracias por la corrección. De todas formas el punto creo que sigue siendo válido, que un branch en SVN es mucho más "pesado" que un branch en Git.
BorrarExcelente aporte, gracias
ResponderBorrarUn argumento determinante para elegir GIT por sobre SVN es que viene integrado en Eclipse y sus derivados, y que es utilizado por grandes proveedores de servicios cloud como Amazon AWS. Eclipse trae una interfaz gráfica increíblemente cómoda para trabajar con GIT, además del historial de modificaciones que es independiente del repositorio.
ResponderBorrarYo no tenía idea de cómo funcionaban los controles de versiones hasta que empecé a desarrollar con Aptana (derivado de Eclipse) y ahora soy totalmente dependiente de ellos, y GIT es el paraíso en cuanto a que puede funcionar totalmente offline.
Hola buen post, yo he probado SVN y GIT... mis necesidades no son tan grandes, por ahora asi que cualquiera de los 2 me viene bien. Pero por algunos detalles finalmente me quedo con GIT. Por cierto comentaban de GitHub que es bueno para proyectos open source... Pero para proyectos del trabajo y free no hay nada mejor que https://bitbucket.org
ResponderBorrarSaludos
Saludos,
BorrarAlguien con experiencia podría hacer un análisis comparativo entre los repositorios remotos www.bitbucket.org, www.assembla.com y www.github.com, más allá del propio concepto de ser un repositorio de códigos de forma remota ?
Gracias anticipadas.
Gracias por la información, sin embargo yo estoy usando una tecnica rudimentaria, porque estoy trabajando en un ejecutable, el cual me baso a su número de versión, que el repositorio me da, cuando tengo estable una versión, mi problema es como llevar el control de cada versión a publicar en el servidor, a modo de que cuando vea ese ejecutable con cierto número de version_release_correccion pueda saber que funcionalidades trae incorporado al momento de su compilacion, si me pudieran recomendar otra herramienta, o si me confirman si lo puedo hacer con Git...
ResponderBorrarolvide mencionar que estoy trabajando esto con subversion...
BorrarCon Git lo que se usa es el comando "git tag" para darle un nombre la versión, por ejemplo una etiqueta puede ser "1.0.327"
BorrarNo lo vas a usar para cada commit, pero sí se puede usar para marcar puntos importantes como versiones liberadas.
Si tenés un proceso de armado automático, podrías hacer que al armar una versión de forma exitosa, se marque el último commit que entró en ese armado con el número de versión que le corresponde.
Hola marco, me gustaria aclarar algo, "En Subversion, un branch se usa solamente para congelar una versión" <- esta definición es errada, esto corresponde a un TAG, el BRANCH en efecto se utiliza para realizar ajustes y evitar interferir con los desarrollos del TRUNK, luego los ajustes pueden ser incluidos en el TRUNK al realizar un MERGE.
ResponderBorrarSaludos!
Gracias por el aporte Marcos
ResponderBorrarMi granito de arena. Desde hace más de 10 años he usado CVS, Subversion, y llevo 2 años con Git. Solamente decir que intentar comparar Svn con Git, es como intentar comparar un Ferrari con un Seat 600. Señores, NO HAY COLOR. No digo que SVN sea malo, ojo, digo que no se puede comparar. Cuando TODO los proyectos de software libre van hacia Git, no conozco ningún caso que desde Git se halla ido para SVN, por la sencilla razón que la potencia y flexibilidad que te da Git no te la dará NUNCA SVN.
ResponderBorrar