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".<div><br></div><div>La mejor de las dos herramientas en cuestión que me dé esto, será para mí, la mejor.<br clear="all">

<div>_____<div>Carlos León</div><div>G+: <a href="http://gplus.to/scyros" target="_blank">http://gplus.to/scyros</a></div><div>Twitter: <a href="http://twitter.com/scyros" target="_blank">http://twitter.com/scyros</a></div>

</div>
<br><br><div class="gmail_quote">El 5 de febrero de 2013 16:03, Andrey Antukh <span dir="ltr"><<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div>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.<br>



<br></div><div>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. <br>



</div><div><br></div><div>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".<br></div></div><div class="gmail_extra">


<br><br><div class="gmail_quote">El 5 de febrero de 2013 15:51, Jesus Cea <span dir="ltr"><<a href="mailto:jcea@jcea.es" target="_blank">jcea@jcea.es</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div>On 05/02/13 15:24, Juan Luis Cano wrote:<br>
> Pues a mí eso me parece una limitación bastante seria. Yo estoy<br>
> muy contento de que en Python no haya propiedades ni métodos<br>
> privados verdaderos (se protegen tras una convención de nombres<br>
> pero se pueden acceder), así que siguiendo la filosofía «we are all<br>
> consenting adults here» no veo por qué se ha impuesto que no se<br>
> pueda reescribir la historia.<br>
<br>
</div>La filosofía es que NO se pueda modificar la historia. Eso es bueno.<br>
¿Has leído 1984?. El libro o la peli :)<br>
<br>
La idea es es que para trabajar NO DEBE SER NECESARIO modificar la<br>
historia de un proyecto porque, coño, es la HISTORIA.<br>
<br>
Pero si sigues mi web, igual duermes más tranquilo :-)<br>
<br>
<a href="http://www.jcea.es/artic/mercurial-ircd.htm" target="_blank">http://www.jcea.es/artic/mercurial-ircd.htm</a><br>
<a href="http://www.jcea.es/artic/mercurial-olimpo.htm" target="_blank">http://www.jcea.es/artic/mercurial-olimpo.htm</a><br>
<br>
Por supuesto, lo que sale ahí son reescrituras completas de<br>
repositorios. Editar un commit aquí y allí, un "rebase" por allá, es<br>
MUCHO más sencillo. Que nadie diga "pero es que reescribir la historia<br>
es MUY difícil". Esto son casos tan patológicos y complejos que han<br>
dado para dos artículos. No son ejemplos de reescrituras "normales".<br>
<br>
Pero dejan claro que se puede hacer lo que quieras con el repositorio,<br>
si realmente quieres.<br>
<br>
> ¿Porque puede traer problemas?<br>
<br>
Hay un repositorio. Yo tengo un clon y tú tienes otro. Ahora tú<br>
manipulas la historia de TU copia. Cuando me bajo tu versión, tengo<br>
dos grafos separados: la historia original (que sigue en mi<br>
repositorio) y la tuya, modificada. Ahora supón que hay 20 personas<br>
modificando la historia. Decir que el resultado me parece confuso es<br>
ser suave.<br>
<br>
GIT tiene el mismo problema, claro, pero lo soluciona a nivel<br>
"cultural", abandonando ramas que simplemente desaparecen cuando nadie<br>
más las referencia. Eso supone que esa historia no referenciada, que<br>
era la original, se "pierde" para siempre jamás.<br>
<br>
En las versiones recientes de mercurial aparece el concepto de<br>
changesets "obsoletos". Son changesets que se mantienen en la<br>
historia, pero que no se muestran por defecto. Pero siguen ahí. La<br>
historia se preserva. Y es consistente entre todos los clones.<br>
<br>
Además del problema técnico, para mí hay un problema filosófico: Un<br>
proyecto NO debe reescribir su historia de forma rutinaria. No debe<br>
ser necesario (salvo "rebase" locales) para trabajar. Pero debe ser<br>
posible si es necesario. Mercurial se atiene a eso.<br>
<div><br>
> Las limitaciones son una forma naïve de protegerte y luego te la<br>
> juegan cuando te la quieres saltar, como bien describiste en tu web<br>
> al migrar los repos de IRC hispano.<br>
<br>
</div>Ah, sigues mi web o mis twits :-).<br>
<br>
Lo que describo en esos enlaces es cirugía mayor. Como ves, Mercurial<br>
lo permite. Naturalmente, para "reescrituras" "normales", es MUCHO más<br>
sencillo. Y hay múltiples formas: exportando changesets, rebase,<br>
mercurial queues, histedit y un montón más.<br>
<br>
La clave no es que no se pueda hacer, la clave es que NO debe hacerse.<br>
No debe formar parte del ciclo de desarrollo del proyecto, rutina.<br>
<div><br>
> Aparte de esto no he manejado ninguno de los dos sistemas en<br>
> profundidad, y hg mucho menos que git, pero lo que leo siempre<br>
> sobre mercurial es que los branches son poco menos que una broma.<br>
<br>
</div>Es una queja habitual, y por eso se añadieron los "bookmarks". En<br>
mercurials modernos, tienes las dos opciones, a elegir. Además de<br>
simplemente clonar el repositorio para desarrollar una feature<br>
concreta, que es lo que suelo hacer yo (clonar en local es "barato" en<br>
velocidad y en espacio en disco).<br>
<br>
Insisto, no obstante que hay diferencias culturales, y no me sorprende<br>
que la gente de GIT considere "bromas" hechos fundacionales de<br>
Mercurial que los "nativos" amamos y apreciamos.<br>
<br>
A mí que GIT "pierda" commits abandonados (y que por definición se<br>
pueden eliminar, porque no hay referencias a ellos... ahora) me da<br>
escalofríos no porque sea peligroso o malo (no lo es), sino porque<br>
supone pérdida de historia del proyecto.<br>
<br>
Reescribir la historia es "normal" en GIT, y una aberración a evitar<br>
(pero posible) en Mercurial. Como digo, diferencias culturales y<br>
filosóficas, y ya he dicho qué prefiero yo.<br>
<div><br>
- --<br>
Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/<br>
<a href="mailto:jcea@jcea.es" target="_blank">jcea@jcea.es</a> - <a href="http://www.jcea.es/" target="_blank">http://www.jcea.es/</a>     _/_/    _/_/  _/_/    _/_/  _/_/<br>
jabber / <a href="mailto:xmpp%3Ajcea@jabber.org" target="_blank">xmpp:jcea@jabber.org</a>         _/_/    _/_/          _/_/_/_/_/<br>
.                              _/_/  _/_/    _/_/          _/_/  _/_/<br>
"Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/<br>
"My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/<br>
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.10 (GNU/Linux)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iQCVAwUBUREceJlgi5GaxT1NAQLt5gP+Is8gtyaQpnoCdwSGoKhsEcJ7j/i17TYp<br>
46SeRnp4WeR6GLgILRcTp55bKGP5TidRILj1PnZAOAAo+JXufCnBPOSZnI/3TUJa<br>
K8QDshutkD1JtlCkJ7Yh7gaqokJW7mq4n27M4Ri6m7SpJdkqf8IQyeLpqijei91F<br>
kvQ2mgDOx8E=<br>
=m9fb<br>
-----END PGP SIGNATURE-----<div class="im"><br>
<div><div>_______________________________________________<br>
Madrid mailing list<br>
<a href="mailto:Madrid@lists.es.python.org" target="_blank">Madrid@lists.es.python.org</a><br>
<a href="https://lists.es.python.org/listinfo/madrid" target="_blank">https://lists.es.python.org/listinfo/madrid</a></div></div></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>

-- <br>Andrey Antukh - Андрей Антух - <<a href="mailto:niwi@niwi.be" target="_blank">niwi@niwi.be</a>><br>
<a href="http://www.niwi.be/about.html" target="_blank">http://www.niwi.be/about.html</a><br><a href="http://www.kaleidos.net/A5694F/" target="_blank">http://www.kaleidos.net/A5694F/</a><br><br>"Linux is for people who hate Windows, BSD is for people who love UNIX"<br>


"Social Engineer -> Because there is no patch for human stupidity"
</font></span></div>
<br>_______________________________________________<br>
Madrid mailing list<br>
<a href="mailto:Madrid@lists.es.python.org">Madrid@lists.es.python.org</a><br>
<a href="https://lists.es.python.org/listinfo/madrid" target="_blank">https://lists.es.python.org/listinfo/madrid</a><br></blockquote></div><br></div>