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

[Andrey Antukh]

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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.es.python.org/pipermail/madrid/attachments/20130205/45c48365/attachment-0001.html>