[Py-MAD] Mercurial vs git (antes: Reunión python-madrid febrero 2013)

Tue Feb 5 16:12:33 CET 2013

EMHO, creo que una buena herramienta te debe dar libertad para poder
"cagarla" (porque no somos perfectos) y a la vez tener posibilidades de
arreglar la "cagada".

La mejor de las dos herramientas en cuestión que me dé esto, será para mí,
la mejor.
_____
Carlos León
G+: http://gplus.to/scyros
Twitter: http://twitter.com/scyros

El 5 de febrero de 2013 16:03, Andrey Antukh <niwi at niwi.be> escribió:

> La limitacion deberia ser por consenso no por implementacion, como bien he
> dicho, no todos somos perfectos y debemos poder modificar cosas, si la
> herramienta no te permite eso, es una deficiencia de la herramienta.
>
> Por otro lado, que tiene que ver borrar branches con el historico...? yo
> hago una branch temporal, subo trabajo con ella durante unos dias y mi
> resultado lo mergeo a default... el historico valido es el que mergeo a
> master, a nadie le importa mis comits parciales y temporales que haya
> hecho... y eso la herramienta debe permitirlo de manera facil, no veo que
> mercurial eso sea facil.
>
> Enserio, la herramienta tiene que ayudarte a trabajar y no ponerte
> trabajas o las cosas dificiles y no intuitivas por solo el hecho de que son
> "peligrosas".
>
>
> El 5 de febrero de 2013 15:51, Jesus Cea <jcea at jcea.es> escribió:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/02/13 15:24, Juan Luis Cano wrote:
>> > Pues a mí eso me parece una limitación bastante seria. Yo estoy
>> > muy contento de que en Python no haya propiedades ni métodos
>> > privados verdaderos (se protegen tras una convención de nombres
>> > pero se pueden acceder), así que siguiendo la filosofía «we are all
>> > consenting adults here» no veo por qué se ha impuesto que no se
>> > pueda reescribir la historia.
>>
>> La filosofía es que NO se pueda modificar la historia. Eso es bueno.
>> ¿Has leído 1984?. El libro o la peli :)
>>
>> La idea es es que para trabajar NO DEBE SER NECESARIO modificar la
>> historia de un proyecto porque, coño, es la HISTORIA.
>>
>> Pero si sigues mi web, igual duermes más tranquilo :-)
>>
>> http://www.jcea.es/artic/mercurial-ircd.htm
>> http://www.jcea.es/artic/mercurial-olimpo.htm
>>
>> Por supuesto, lo que sale ahí son reescrituras completas de
>> repositorios. Editar un commit aquí y allí, un "rebase" por allá, es
>> MUCHO más sencillo. Que nadie diga "pero es que reescribir la historia
>> es MUY difícil". Esto son casos tan patológicos y complejos que han
>> dado para dos artículos. No son ejemplos de reescrituras "normales".
>>
>> Pero dejan claro que se puede hacer lo que quieras con el repositorio,
>> si realmente quieres.
>>
>> > ¿Porque puede traer problemas?
>>
>> Hay un repositorio. Yo tengo un clon y tú tienes otro. Ahora tú
>> manipulas la historia de TU copia. Cuando me bajo tu versión, tengo
>> dos grafos separados: la historia original (que sigue en mi
>> repositorio) y la tuya, modificada. Ahora supón que hay 20 personas
>> modificando la historia. Decir que el resultado me parece confuso es
>> ser suave.
>>
>> GIT tiene el mismo problema, claro, pero lo soluciona a nivel
>> "cultural", abandonando ramas que simplemente desaparecen cuando nadie
>> más las referencia. Eso supone que esa historia no referenciada, que
>> era la original, se "pierde" para siempre jamás.
>>
>> En las versiones recientes de mercurial aparece el concepto de
>> changesets "obsoletos". Son changesets que se mantienen en la
>> historia, pero que no se muestran por defecto. Pero siguen ahí. La
>> historia se preserva. Y es consistente entre todos los clones.
>>
>> Además del problema técnico, para mí hay un problema filosófico: Un
>> proyecto NO debe reescribir su historia de forma rutinaria. No debe
>> ser necesario (salvo "rebase" locales) para trabajar. Pero debe ser
>> posible si es necesario. Mercurial se atiene a eso.
>>
>> > Las limitaciones son una forma naïve de protegerte y luego te la
>> > juegan cuando te la quieres saltar, como bien describiste en tu web
>> > al migrar los repos de IRC hispano.
>>
>> Ah, sigues mi web o mis twits :-).
>>
>> Lo que describo en esos enlaces es cirugía mayor. Como ves, Mercurial
>> lo permite. Naturalmente, para "reescrituras" "normales", es MUCHO más
>> sencillo. Y hay múltiples formas: exportando changesets, rebase,
>> mercurial queues, histedit y un montón más.
>>
>> La clave no es que no se pueda hacer, la clave es que NO debe hacerse.
>> No debe formar parte del ciclo de desarrollo del proyecto, rutina.
>>
>> > Aparte de esto no he manejado ninguno de los dos sistemas en
>> > profundidad, y hg mucho menos que git, pero lo que leo siempre
>> > sobre mercurial es que los branches son poco menos que una broma.
>>
>> Es una queja habitual, y por eso se añadieron los "bookmarks". En
>> mercurials modernos, tienes las dos opciones, a elegir. Además de
>> simplemente clonar el repositorio para desarrollar una feature
>> concreta, que es lo que suelo hacer yo (clonar en local es "barato" en
>> velocidad y en espacio en disco).
>>
>> Insisto, no obstante que hay diferencias culturales, y no me sorprende
>> que la gente de GIT considere "bromas" hechos fundacionales de
>> Mercurial que los "nativos" amamos y apreciamos.
>>
>> A mí que GIT "pierda" commits abandonados (y que por definición se
>> pueden eliminar, porque no hay referencias a ellos... ahora) me da
>> escalofríos no porque sea peligroso o malo (no lo es), sino porque
>> supone pérdida de historia del proyecto.
>>
>> Reescribir la historia es "normal" en GIT, y una aberración a evitar
>> (pero posible) en Mercurial. Como digo, diferencias culturales y
>> filosóficas, y ya he dicho qué prefiero yo.
>>
>> - --
>> Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
>> jcea at jcea.es - http://www.jcea.es/     _/_/    _/_/  _/_/    _/_/  _/_/
>> jabber / xmpp:jcea at jabber.org         _/_/    _/_/          _/_/_/_/_/
>> .                              _/_/  _/_/    _/_/          _/_/  _/_/
>> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
>> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
>> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQCVAwUBUREceJlgi5GaxT1NAQLt5gP+Is8gtyaQpnoCdwSGoKhsEcJ7j/i17TYp
>> 46SeRnp4WeR6GLgILRcTp55bKGP5TidRILj1PnZAOAAo+JXufCnBPOSZnI/3TUJa
>> K8QDshutkD1JtlCkJ7Yh7gaqokJW7mq4n27M4Ri6m7SpJdkqf8IQyeLpqijei91F
>> kvQ2mgDOx8E=
>> =m9fb
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> Madrid mailing list
>> Madrid at lists.es.python.org
>> https://lists.es.python.org/listinfo/madrid
>>
>
>
>
> --
> Andrey Antukh - Андрей Антух - <niwi at niwi.be>
> http://www.niwi.be/about.html
> http://www.kaleidos.net/A5694F/
>
> "Linux is for people who hate Windows, BSD is for people who love UNIX"
> "Social Engineer -> Because there is no patch for human stupidity"
>
> _______________________________________________
> Madrid mailing list
> Madrid at lists.es.python.org
> https://lists.es.python.org/listinfo/madrid
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20130205/0d30dda8/attachment.html>