Re: [Python-es] Traduccion libro Mercurial a Español [Offtopic]

[Rafael Villar Burke]

Chema Cortes wrote:
> Antes de nada, significar que habría que haber señalado este tema como
> [offtopic]
>
> El día 22 de enero de 2009 12:33, Francesc Alted <faltet en pytables.org> escribió:
>
>   
>> No tengo experiencia en Mercurial, pero si en bzr, y la verdad que estoy
>> bastante satisfecho.  Podrías explicar un poco el porqué me merecería
>> la pena cambiar?
>>     
>
> La verdad es que también me interesaría conocer alguna comparativa. En
> este libro hay una sección que compara algunos controladores de
> versiones: mercurial, CVS, subversion, git,.. No dice nada de bazaar.
>   
Tanto mercurial (hg) como git y bazaar (bzr) son distribuidos y de
tercera generación, por lo que son muy similares en arquitectura y forma
de funcionamiento (y funcionalidad). Las diferencias entre ellos son más
de matiz pero pueden hacer que uno se sienta más a gusto trabajando en
uno que en otro. Aquí comento mi experiencia con los tres (los uso con
cierta frecuencia, especialmente mercurial y git).
> Lo que está claro es que hay dos tipos: centralizados y distribuídos.
> De los centralizados creo que destaca subversion, que es el único que
> utilizo en mi trabajo.
Es el más popular de entre los sistemas libres y es el "sucesor" de CVS,
respecto al cual incorpora muchas mejoras.
>  Destaca por la menor sobrecarga para trabajar
> con ficheros binarios que los sistemas distribuídos, que engordan
> tremendamente con cada revisión.
>   
Esto no es técnicamente correcto ya que el incremento de tamaño
dependerá de cómo se computan los cambios entre versiones (respecto a la
versión anterior, respecto a la versión previa de cada archivo, etc).

En general, un repositorio (almacén de datos con toda la historia de los
mismos) de un sistema distribuido tiende a ser bastante menor que una
copia (checkout) de los datos que guarda, aunque es cierto que si
existen muchos archivos binarios grandes el tamaño puede incrementarse
mucho con el tiempo (otra cuestión es si almacenar archivos binarios de
ese tipo es lo más adecuado).

[ Si has probado git, es probable que esto, junto con el hecho de que no
hace "recolección de basura" de forma automática haya producido un
incremento grande del almacenamiento. Haciendo un "reempaquetado"
(volver a calcular las diferencias entre versiones para optimizarlas) se
podría solucionar. También, creo que git ya hace "recolección de basura"
(eliminar los objetos/datos que ya no se utilizan) de forma automática y
periódica.

Tanto mercurial como bazaar realizan recolección de basura de forma
automática.

En Mercurial también se notaría el efecto de los cambios en archivos
binarios grandes si se producen muy intercalados ya que, para reducir el
tiempo de búsqueda de datos, se hace una copia completa del archivo en
determinadas condiciones para lograr tiempos de búsqueda lineal respecto
al número de cambios. ]
> Entre los distribuídos, utilicé algo el monotone, por lo que me
> decanté por el git, que hereda bastante de su funcionalidad y es
> rapidísimo en los merges. Pero, después de ver la comparación entre
> git y mercurial, creo que tendré que dar una oportunidad a éste
> último. Puede funcionar en paralelo con subversion y no se contiene
> bastante antes de expandirse.
>   
En mi opinión, el principal problema de git es que expone excesivos
detalles al usuario, al haber ido modelando su interfaz con el paso del
tiempo, lo que da lugar a inconsistencias y a que exija comprender
bastante bien los detalles de implementación para trabajar con eficacia
(y, posiblemente, no perder datos en alguna ocasión).

Tanto mercurial como bazaar tienen una interfaz más cuidada desde el
principio y resultan mucho más sencillos de aprender y comprender.

En cuanto a prestaciones, los tres tienen funcionalidades muy similares,
aunque git y mercurial son mucho más rápidos que bazaar.

Otra cosa relevante para esta lista es que tanto bazaar como mercurial
están programados en python y es muy sencillo realizar extensiones para
añadir funcionalidades específicas. El código de Mercurial es, además,
uno de los más brillantes e interesantes que conozco (compacto, conciso,
claro y muy pythónico).

Cosas que me gustan de Mercurial (ya hablando de mi preferido):
- Muy fácil de instalar (git necesita perl, bash, python...)
- Muy fácil de aprender. Al tener una interfaz muy homogénea no hay
muchas sorpresas y la forma de uso es bastante predecible.
- El sistema de extensiones, que permite ampliar las funcionalidades
básicas. Las hay para realizar cambios en bugzilla al guardar datos,
para modificar la historia, para resaltado de sintaxis, para enviar
series de parches por correo, para gestionar parches hasta que se
integran en un proyecto, para trabajar de forma bidireccional con
Subversion... 
http://www.selenic.com/mercurial/wiki/index.cgi/UsingExtensions
- Compatibilidad. Funciona en cualquier sistema que funcione python.
Hasta existe un cliente gráfico tipo Tortoise, el TortoiseHg (
http://tortoisehg.sourceforge.net/ ) que funciona en windows y GNU/Linux
/ Unix.
- Servidor web integrado que arranca simplemente con: hg serve   (aunque
existen script wsgi para usar con otros servidores).
- Escala muy bien. Yo lo uso para proyectos muy pequeños, pero proyectos
mastodónticos como OpenSolaris, Xen, Mozilla o OpenJDK lo usan también.
- Junto con git, es rapidísimo, mucho más que bazaar, y normalmente las
limitaciones vienen de la velocidad de lectura escritura en disco (no de
procesado, a pesar de ser en python).
- Seguro. Es necesario activar expresamente las extensiones que pueden
producir pérdidas de datos al modificar la historia de cambios, por lo
que únicamente se está expuesto a la complejidad que uno necesita en
cada momento.
> No veo un claro destacado. Dependerá mucho del tipo de proyecto
> distribuído que se vaya a controlar.
>   
Hoy en día yo no me lo pensaría, elegiría entre Mercurial o git, y el
primero me parece personalmente más usable, más fácil de instalar (muy
pocas o ninguna dependencia salvo un compilador de C para algunas
extensiones si se quiere ganar velocidad en lugar de usar las
implementaciones en python).

Saludos,

Rafael Villar Burke
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes