TortoiseHg no sólo está para Windows, se encuentra disponible para Nautilus Gracias a una búsqueda de otra cosa me di cuenta recién. Acá están las instrucciones para usarlo, y hay screenshots también. Lo instalé, funciona perfecto, y parece que está muy muy bueno.

Yo personalmente creo que vale la pena aprender a usarlo, simplemente porque es una herramienta superior, y está desplazando a los sistemas centralizados. Por supuesto que para hacer los TPs basta con algo como Subversion, pero pienso que hasta ahí nomás.

Lo hablamos más personalmente

Aclaro que la introducción era un chiste No estoy diciendo que tengamos que cambiar ya a Mercurial, simplemente me parece superior (o sea, la arquitectura es superior), y como vos decís, Subversion nos alcanza y sobra para lo que hacemos. Pero se podrían presentar algunas situaciones (¿te acordas cuando preparábamos el paper para las JAIIO en la facu, que no teníamos acceso al repositorio SVN?) en las que las restricciones del modelo de Subversion/CVS pueden joder un poco.

Más allá de los commits locales, todas las operaciones en general son locales, o sea más rápidas, incluso si comparás Mercurial con el método “ra_local” de Subversion, que es el más rápido que tiene. Hay ventajas en lo que respecta al manejo de archivos renombrados por ejemplo (aunque en Subversion 1.5 ya lo incluyeron, pero no se qué tan maduro está). Dependes menos del buen funcionamiento de la red/Internet. Es más seguro: el repositorio se encuentra en todos los desarrolladores (si el server SVN muere y no hiciste backups, perdiste toda la historia de tu proyecto).

Con respecto a los proyectos de Software Libre, representan una gran, gran ventaja. Imaginate que queres bajarte el código de algún proyecto y queres hacer unos cambios. Con un sistema distribuido como Mercurial, clonas el repositorio (un checkout digamos), haces cambios, commiteas, y todas las operaciones que quieras (ya que tenes ahí el repositorio). Si queres compartir los cambios, le decis al mantenedor que pullee de tu repositorio (es super sencillo esto) para obtener tus cambios (algo así es el modo de colaboración entre los desarrolladores de Linux). En un sistema centralizado, haces un checkout, y no podes commitear, a menos que tengas permisos en el servidor. Esto es bastante desventajoso.

Los sistemas distribuidos son muy, muy escalables, por su arquitectura. Un sistema centralizado pierde feo en este punto… justamente, es centralizado. Si tenés un proyecto gigantesco (notar que me estoy yendo de nuestra situación de hacer trabajos prácticos obviamente, ya lo aclaré arriba), se puede complicar bastante con un solo servidor. En un DVCS no existe este problema.

No me acuerdo bien como es el proceso de merge en Subversion, pero lo poco que recuerdo del manual es que si bien lo haces con un comando (o algunos más), es un poco complicado. Esto lo recuerdo borrosamente digamos. De todas formas hay desventajas mas importantes: cuando haces un merge, Subversion no maneja la historia de ese branch. O sea que no podes saber qué commits (o changesets) fueron fusionados. El merge es como un solo commit más, con un log, digamos, tipo “fusiono los cambios del branch X”. Si bien esto empieza a cambiar con la versión 1.5, se ha implementado lo básico (obviamente, está un [o unos] pasos atrás que los sistemas distribuidos).

Fijate en los screenshots que puse en el post (con “hg view”), especialmente el último: si la operación de encontrar el commit que introdujo el bug hubiera sido más compleja y me hubiera demandado más commits, podría haber hecho un branch, trabajar tranquilo, y después fusionarlo. En realidad ésta hubiese sido la forma correcta de hacerlo. Y al fusionarlo en trunk (digamos), vería todos los commits hechos en el branch. Es más, esto de hacer un branch aparte para trabajar tranquilo y en aislamiento es lo que se recomienda hacer en Mercurial. Es la forma común de trabajar: hacer branches. En Subversion esto siempre se trata de evitar, porque es más complejo.

¿Por qué estoy tan seguro de que es mejor el proceso de branch/merge en los sistemas distribuidos que en Subversion o centralizados? Porque así lo afirman los desarrolladores de grandes proyectos de Software Libre, donde tienen que lidiar con esto de hacer branches/merges muchísimo. Mirá este comentario (que podés encontrar acá, donde habla de las ventajas de Git): “Merging branches is very pleasant. CVS and SVN always made this hard.”

Algunos quotes más (muchas cosas se aplican a todos los sistemas distribuidos, no exclusivamente a los nombrados):

• Git – SVN Crash Course: “Git supports merging between branches much better than Subversion”
• Git’s Major Features Over Subversion: “Branches in Git are a core concept used everyday by every user. In Subversion they are almost an afterthought and tend to be avoided unless absolutely necessary.”
• Bazaar vs Subversion: “Better merging – fully integrated and works across distributed repositories “
• Mercurial versus Subversion (Mark J. Wielaard) (acá dice cosas más allá del tema branch/merge): “The benefits are really huge. Not only is making diffs between any two versions of any files instant once you have a local mercurial clone, it also gives you an easy way to experiment with your local patches and have them under version control, creating, merging and generating meaningful diffs between branches is much nicer than with subversion, and it is much, much more space efficient than subversion. A checkout of 1 revision of openjdk with subversion is 1.2GB, the whole mercurial repo, which includes all revisions, takes just 740MB disk space. Amazing.”

Fijate en ese último comentario algo que te había dicho una vez: todo el repositorio Mercurial es mucho más eficiente con respecto al espacio en disco requerido que una copia de trabajo Subversion (o sea, estamos hablando de cosas totalmente distintas… por lo menos si estaríamos comparando con el repositorio de Subversion).

Mirá este post en VivaLinux. Los mismos desarrolladores ven el concepto de Subversion ya agotado, si bien eso no significa que se deje de utilizar, sino que, en resumen, el futuro será para los sistemas distribuidos.

Sin embargo, Subversion es mejor para grandes archivos binarios, debido a su arquitectura (en este caso en particular es una ventaja). En esta situación, Subversion permite también hacer un lock de los archivos (cosa que estuvimos usando con los poster… bueno… “usando”). Hacer eso, un lock, en un DVCS no tiene sentido. SVN está más soportado en general, sin embargo esto va a ir cambiando gradualmente. Y con respecto a la documentación, los dos (Mercurial y Subversion) me parece están muy bien.

Los comandos de Mercurial son muy parecidos a los de Subversion, por lo que aprender a usarlo sería muy fácil. No veo desventajas en usar, en este caso, una bomba atómica para matar un mosquito: es un sistema mejor, se perfila como la arquitectura del futuro, su uso prácticamente implica ventajas en todos los sentidos, y sobre todo: aprender a usarlo es fácil (y más si sabes Subversion), etc. Si fuese algo totalmente raro y distinto sería otra cosa…

Me gustaría que me plantearas un caso donde se complica el merge un un branch con el trunk (hacia o desde) y donde Mercurial lo maneje mejor (podríamos resolver uno cada uno).

Veo que es muy potente la herramienta, pero sin embargo para el uso que le damos creo que Subversion nos sobra. Si bien podríamos utilizar Mercurial como estamos utilizando Subversion ahora, cambiando apenas la sintaxis de uso, creo que sería matar un mosquito con un cañon.

Al margen de esto creo que sería útil en un grupo de trabajo grande, pero donde todos conozcan bien la herramienta. No veo (capaz porque no se me presentó el problema y no lo veo acá) las ventajas aparte de la de poder hacer commits locales (con lo cual podría hacer más atómicas mis modificaciones).

Voy a buscar más info y si encuentro algo interesante te lo pego acá debajo y vemos como se resolvería.

Buen post