Comentarios

1. Que interesante, me imagino que a corto plazo, van a crear un módulo de integración para Mercurial-NetBeans. Y ahí van dos grandes proyectos mas que también dejan CVS (¿quien conoce a alguno que aún esté con CVS?).

   Ojalá de paso, modifiquen las dependencias entre los diferentes módulos de NetBeans. La última vez que quize bajarme un módulo para realizar modificaciones, me encontré con que debía bajarme todo el contenido del repositorio CVS o algo por el estilo (unos ~850 MB, ¡mediante Dial-up!...).

   Tal parece que la mayoría de los proyectos de software libre están apostando por los sistemas de control de versiones distribuidos. Me pregunto que posición tomará dev.java.net (sitio que utiliza servicios de CollabNet), Apache (uno de los primeros, sino el primero que migró a Subversion), JBoss, SourceForge, Codehaus y otras tantas comunidades que albergan proyectos de software libre.

   Sin duda la adopción de Mercurial por parte de grandes proyectos como ellos, será de gran valor como experiencia para sus hermanos pequeños dispersos alrededor del planeta.

   Johans Marvin Taboada Villca on Monday, 17 December 2007, 21:43 BOT # |

2. Bueno, a un principio con mercurial no podría bajarse un "subdirectorio", como funciona subversión donde cada subdirectorio es un repositorio en si.

   Pero apareció el plugin "forest" que otorga esa característica,  y que los grandes proyectos lo estan usando. Por que sino, para modificar o hacer una ramificación de una librería se tendría que bajar toda la historia... que tranquilamente podría pasar el orden de GB.

   Tambien opensolaris esta usando mercurial, sin duda sólo existen dos opciones viables -opensource- para dvcs: mercurial y git.

   Lo malo de git -a parte de estar en c- es que no tiene buen soporte para windows y la interface es bien complicada.

   Comparado con mercurial, git es un poco más rápido, luego mercurial tiene mejor soporte multiplataforma por estar hecho en python, y las partes críticas (I/O) en c para mejorar el performance.

   Tendrías que leer la charla de torvalds sobre git, donde le da palo a subversion, donde por una parte svn se jacta de tener un branching cheap, pero en el fondo el desarrollo en equipo es más que todo sobre merging de branchs, ahí es donde svn es una *****. 

   En cambio en mercurial es lo más natural, y se conserva la historia. 

   Si usan ubuntu bolivia ya viene en el cd addons: apt-get install mercurial

   Sino de internet, aunque es pequeño y no tiene grandes dependencias. 

   Incluso se puede configurar sin problemas en shared hosting sin acceso shell. 

   Rho on Monday, 17 December 2007, 23:17 BOT # |

3. Como se configura mercurial en Ubuntu-Bolivia

   Nely on Tuesday, 18 December 2007, 16:37 BOT # |

4. @Nely@3

   No creo que se tenga que configurar nada (a menos que quieras configurar un servidor), como cliente, Mercurial se utiliza mediante un solo binario (si no me equicovo): hg, mediante este y los subcomandos que provee realizas tareas como:

   • Obtener ayuda de los subcomandos disponibles [hg help]
     
   • Clonar repositorios [hg clone ...] (~similar a obtener copias de trabajo~, sólo que más sofisticadas) .
   • Explorar cambios locales [hg diff ...].
   • Publicar cambios a tu rama [hg commit ...].
   • etc, etc

   @Pablo publicó anteriormente un par de enlaces respecto a VCs y DVCs (por si acaso):

   • Control de versiones ... con chuis.
   • Control de versiones distribuido ... con chuis.
     

   @Rho@2:

   No se porque todos le dan tanto palo a Subversion si lo único que quisieron hacer desde un principio es un reemplazo para CVS, ¿es tan malo eso? (Además lo del fusionar ramas va a ser mejorado, en el apunto de salir, Subversion-1.5).

   Yo personalmente, preferiría utilizar Subversion para introducir a estudiantes a los Sistemas de Control de Versiones. Sobre esta base, los DVCs no son tan difíciles de entender.

   Además Mercurial no inventó lo de DVCs (ya existían Git, Darcs, Bazaar, por ejemplo), Subversion pudo haber elegido ser distribuido (también fué escrito desde cero), pero la decisión debe haber tenido algún fundamento ¿cuál será?, ¿les estará pesando esa decisión ahora que la popularidad de los DVCs está creciendo? tal vez sí .

   Por otra parte, si bién mencionas que Mercurial implementa partes críticas en C (I/O), ¿Que opciones de integración provee para otros lenguajes?. ¿Expone su API de alguna forma usable por otros lenguajes? (Subversion usa SWIG por ejemplo).

   Pregunto porque probé un plugin que da soporte Mercurial para Eclipse (cloné el repo de ajayu con este), pero el desempeño es una lágrima (invoca directamente al binario de Mercurial instalado, un comando a la vez).

   Podrías argumentar que Mercurial es extremadamente fácil de usar y no requiere un IDE, pero eso no esta en discusión. Otros requerimos integración si o si (si no fuere así no hubieran creado dicho plugin).

   Alguna luz que no sea necesariamente Pythonesca?.

   Johans Marvin Taboada Villca on Tuesday, 18 December 2007, 19:16 BOT # |

5. En palabras de linus: 

   When I say I hate CVS with a passion, I have to also say that if there any SVN users (Subversion users) in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started, because the whole slogan for the Subversion for a while was 'CVS done right' or something like that. And if you start with that kind of slogan, there is nowhere you can go. It's like, there is no way to do CVS right.

   ... 

   Merging in subversion is a complete disaster. The subversion people kind of acknowledge this and they have a plan, and their plan sucks too. It is incredible how stupid these people are. They've been looking at the wrong problem all the time. Branching is not the issue, merging is. And merging they did not do squat for, five years after the fact. That is sad.

   Claro que mercurial no invento el concepto de dvcs, ya existían bitkeeper, clearcase, arch, monotone. Los que mencionas son contemporáneos que casi todos -excepto darcs- nacieron por la crisis de linux-bitkeeper.

   Entonces casi paralelamente linus empezó con git, y otro empezo mercurial con el objetivo claro.

   Y el equipo de mercurial lo hizo muy bien en hacer un dvcs escalable, capaz de manejar proyectos inmensos sin problemas, ahora que he tenido que usar otra vez svn  para elgg, me he dado cuenta la diferencia de velocidad entre svn y mercurial (en operaciones como status, diff, etc).

    svn desde un principio quizó ser un reemplazo para cvs, entonces no podían hacerlo descentralizado.

   Para que mercurial exponga su api mediante swig, todo tendría que estar en c, así tendrían su api expuesta.. aunque de fea manera pero expuesta. Esa talvés sea una pregunta para la lista de mercurial ;)

   Una gran desventaja son las herramientas extras, como la integración que mencionas y la "tortuga"  (tortoise) para windows. Aunque existe tortoisehg, es leeento.

   No digo que mercurial es extremadamente fácil de usar, al menos necesitan hacer un "hg help"  xD

   Pero claro, como en cualquier contexto, si la herramienta actual es suficiente para lo que necesitas, no hay razón para cambiarla. Si empiezas a darte cuenta de las limitaciones, entonces es momento para buscar otras alternativas. 

   http://video.google.com/videoplay?docid=-2199332044603874737

   http://git.or.cz/gitwiki/LinusTalk200705Transcript 

    

   Rho on Tuesday, 18 December 2007, 19:57 BOT # |

6. Anque este enlace sale fuera del contexto original de esta conversación, demuestra que la opinión de cualquier personaje es relativamente subjetiva.

   Johans Marvin Taboada Villca on Wednesday, 19 December 2007, 09:16 BOT # |

7. Stallman vs Torvalds en un clásico, unos es más pragmático... y el otro.. bueno, ya sabemos como es el otro =D

   De todas maneras los dos son unos rayados y arrogantes. 

   Rho on Wednesday, 19 December 2007, 14:12 BOT # |