Blog de Marcos Crispino

Creo que es algo bastente común, cuando se está trabajando con distintas versiones del mismo producto, tener que sincronizar cambios de una versión a otra. En particular en Artech tenemos el código en un repositorio SVN, y en este momento tengo cuatro versiones del cliente de iOS en las que estoy trabajando: la versión prácticamente cerrada del Upgrade 2 de la Evolution 2 la rama de upgrades (Upgrade 3 y posteriores) de la Evolution 2 la versión oficial de Tilo (nombre código de la próxima versión de GeneXus)  una versión inestable de Tilo donde estoy haciendo cambios que no quiero hacer commit porque están "atados con alambre" Llevar los cambios de una versión a otra puede ser bastante complicado, si se trata de un fuente que tiene cambios en más de una versión. Es un proceso bastante manual. Para facilitar este proceso hice un script Bash que se fija los cambios en la versión de origen y muestra el comparador (File Merge, viene con Xcode) para los archivos modifi...

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