<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">El 5 de febrero de 2013 16:41, 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 class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div><div class="im">On 05/02/13 15:42, Andrey Antukh wrote:<br>
>> No todos somos perfectos y no podemos hacerlo todo perfecto desde<br>
>> el inicio. Y la herramienta debe permitir rectificar a<br>
>> posteriori.<br>
<br>
</div>Lo permite. De forma simple, y pero pagando las consecuencias<br>
(historias divergentes en diferentes clones, como es natural e<br>
inevitable).<br>
<div class="im"><br>
> Tengo entendido que los bookmarks son básicamente equivalentes a<br>
> los branches ligeros de GIT. ¿Por qué dices que no es una<br>
> solución?.<br>
><br>
>> Intentan hacer algo parecido a lo que hace git, pero el<br>
>> funcionamiento estandar es distinto. Ejemplo concreto, tengo 2<br>
>> repos, en uno creo bookmark X hago modificacion en un archivo y<br>
>> hago push ... sin el -B, mis cambios se suben, el repo remoto<br>
>> automaticamente tiene mis cambios de mi bookmark... pero no tiene<br>
>> ningun bookmark.<br>
<br>
</div>Es opinable qué vía es la correcta. Se puede argumentar que un<br>
bookmark es algo local, que el "namespace" en cuestión es local, y que<br>
si quieres hacerlo público, tengas que hacerlo de forma explícita. De<br>
la misma forma que si voy a crear un "head" nuevo en el repositorio,<br>
tienes que añadir el "-f" (force) o que un proyecto incluso pueda<br>
poner un "hook" en el servidor para evitar "heads" nuevos (por<br>
ejemplo, cpython).<br>
<br>
Pero voy a darte una alegría:<br>
<br>
Mercurial 2.3, publicado en Agosto:<br>
<br>
"""<br>
bookmarks: pull new bookmarks from remote by default (backward<br>
incompatible change)<br>
"""<br></blockquote><div><br></div><div style>Tenia constancia de ello, pero aun asi, como mi ejemplo señala un push no tiene que afectar al repo remoto y no todos deben estar obligados a usar bookrmarks para que yo pueda usarlos.</div>
<div style><br></div><div style>He hecho push... estando en default... es decir... no he tenido la intencion de subir mis cambios del bookmark pero mercurial si lo ha hecho. Si tengo que usar otras cosas... para que no se haga ese push, la herramienta tiene deficiencias en el core. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Esto es para importar bookmarks ajenos. Para publicarlos, tienes que<br>
ser explícito. Si tu práctica habitual es subir bookmarks nuevos (los<br>
que ya hayas sincronizado, se actualizan automáticamente), puedes<br>
definir parámetros por defecto con una línea en el fichero de<br>
configuración (donde de todas formas tienes que poner cosas como tu<br>
usuario y clave, extensiones activadas, etc). Esto forma parte de la<br>
cultura del propio proyecto.<br>
<br>
<a href="http://mercurial.selenic.com/wiki/Bookmarks#Transferring_bookmarks" target="_blank">http://mercurial.selenic.com/wiki/Bookmarks#Transferring_bookmarks</a></blockquote><div><br></div><div style>Vuelvo a decir, que yo quiera usar bookmark no quiere decir que los demas tienen que usarlos.</div>
<div style>El ejemplo que he mandado muestra claramente que mi cambio en un bookrmark a afectado a otro repo que no tenia bookrmarks... ya que le ha puesto el cambio que he hecho en un bookmark a en su default... NO DEBERIA HACER ESO, y no es cuestion de herramienta... o mi condicionamiento con git... si algo que es "branch ligera" es una branch ... y debe trarase como tal... es decir si yo pusheo mis cambios en esa "branch" deben estarn en esa branch y no afectar de ninguna manera al default del resto... pero SI lo hace. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div class="im"><br>
>> Ese comportamiento es totalmente herratico, si subo mis<br>
>> cambios... es por que quiero subirlos pero no quiero afectar a<br>
>> nadie mas... subia mis cambios en mi bookmark...<br>
<br>
</div>Si todo el mundo en tu proyecto usa bookmarks, tus cambios no afectan<br>
al resto... a menos que hayas movido los bookmarks.<br></blockquote><div><br></div><div style>Y si no? Vamos a obligar a todos a usar bookmarks solo por que la herramienta lo obliga? Enserio.. la herramienta tiene que adecuarsea a tu trabajo no tu trabajo a la herramienta. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Precisamente si no quieres afectar a nadie más, lo que NO quieres es<br>
subir tus bookmarks locales, que es lo que hace mercurial por defecto.<br></blockquote><div><br></div><div style>Pero si quiero subir mis bookmarks por que quiero trabajar en ellos desde casa sin afectar a nadie. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Subiendo tus cambios sin un bookmark asociado crea un nuevo "tip". Ver<br>
más abajo.<br>
<div class="im"><br>
>> [2/4.3.17]foo@foo:~> hg clone foo/ foo2 updating to branch<br>
>> default 1 files updated, 0 files merged, 0 files removed, 0 files<br>
>> unresolved [2/4.3.17]foo@foo:~> cd foo2/<br>
>> [2/4.3.17]foo@foo:~/foo2> hg bookmark master<br>
>> [2/4.3.17]foo@foo:~/foo2> hg bookmark bug1<br>
>> [2/4.3.17]foo@foo:~/foo2> echo file1.txt 1<br>
>> [2/4.3.17]foo@foo:~/foo2> echo "2" > file1.txt<br>
>> [2/4.3.17]foo@foo:~/foo2> hg commit -m "fix bug1"<br>
>> [2/4.3.17]foo@foo:~/foo2> hg update master 1 files updated, 0<br>
>> files merged, 0 files removed, 0 files unresolved<br>
>> [2/4.3.17]foo@foo:~/foo2> echo file1.txt 1<br>
>> [2/4.3.17]foo@foo:~/foo2> hg push pushing to /home/foo/foo<br>
>> searching for changes adding changesets adding manifests adding<br>
>> file changes added 1 changesets with 1 changes to 1 files<br>
>> [2/4.3.17]{255}foo@foo:~/foo2> hg bookmarks bug1<br>
>> 1:7cc28568e142 * master 0:0d4d5e9e6508<br>
>> [2/4.3.17]foo@foo:~/foo2> cd .. [2/4.3.17]foo@foo:~> cd foo<br>
>> [2/4.3.17]foo@foo:~/foo> hg update 1 files updated, 0 files<br>
>> merged, 0 files removed, 0 files unresolved<br>
>> [2/4.3.17]foo@foo:~/foo> hg bookmarks no bookmarks set<br>
>> [2/4.3.17]foo@foo:~/foo2> echo file1.txt 2<br>
<br>
</div>Si no usas bookmarks, un "update" te manda al "tip". Osea, a la<br>
versión más reciente del repositorio. Normalmente es lo que se quiere,<br>
y de hecho es lo que estás pidiendo. "hg update" significa "mándame a<br>
la versión más reciente del proyecto".<br>
<br>
Sí, cuando un proyecto tiene varios "heads", moverse al "head más<br>
moderno" puede ser confuso, porque depende de lo que esté haciendo el<br>
resto de la gente, pero ciertamente es justo lo que le has pedido.<br>
<br>
Si el usuario estuviese trabajando en un "bookmark", haría "hg up<br>
BOOKMARK", y se iría a la versión más reciente de ese "bookmark".<br>
<br>
Puede discutirse que si estamos en un "bookmark", un "hg up" debería<br>
moverse al "head" de ese "bookmark", sin tener que indicarlo de forma<br>
explícita. Corregirlo es una linea en el fichero de configuración.<br>
<br>
En todo caso estás buscando trabajar con mercurial igual que trabajas<br>
con GIT. Eso es un error.<br>
<div class="im"><br>
>> Este comportamiento no tiene ningun setido, si subi mis<br>
>> cambios... que en un principio nisiquiera deberia haberlos subido<br>
>> por que hice push no push de un bookmark...<br>
<br>
</div>Push sube tu historia. Puedes marcar changesets como "secretos" para<br>
no publicarlos con un "push" hasta que están listos. Buena forma de<br>
evitar cagadas:<br>
<br>
<a href="http://mercurial.selenic.com/wiki/Phases" target="_blank">http://mercurial.selenic.com/wiki/Phases</a><br>
<div class="im"><br>
>> Y eso es un claro ejemplo de que los bookmakrs no sirven como<br>
>> "git branches" por que las branches de git tienen la potencia de<br>
>> branches de verdad y a la vez son ligeras."<br>
<br>
</div>La única cosa que te acepto aquí es que un "hg update", cuando estamos<br>
en un bookmark, debería mantenerte en ese bookmark. Si este workflow<br>
es rutinario en ese proyecto, que lo haga así es una linea en el<br>
fichero de configuración.<br>
<br>
A mí me parece más sencillo tener un único "head". Las diferentes<br>
features deben desarrollarse en "clones" temáticos. Esa es mi "cultura<br>
de desarrollo". Ni la mía ni la tuya es "mejor". La elección es<br>
cultural y filosófica. GIT tira hacia un lado, Mercurial hacia el<br>
otro. Ambas tienen su justificación.<br>
<div class="im"><br>
>> Bueno, en git lo uso a diario y se como usarlo, si mercurial en<br>
>> las mismas sircunstancias no resuelve algo que si git, entonces<br>
>> el desconocimiento no es una posible opcion. Las otras opciones<br>
>> son totalmente posibles.<br>
<br>
</div>Sin entrar a valorar que sea buena idea que hagas "rebases" a diario<br>
(puede ser lo correcto o una burrada, depende. Yo suelo preferir<br>
"merge", pero depende de la situación), tal vez el hecho de que lo<br>
hagas en GIT a diario y te resulte rutinario penaliza un poco tu<br>
experiencia con Mercurial, donde no lo haces a diario y no te resulta<br>
rutinario en absoluto. Y la cultura "mercurial" tiende a evitar<br>
"rebase", por violar la "filosofía" de que la historia es la HISTORIA,<br>
y no debe modificarse.<br>
<br>
Conduces un coche a diario. Te prestan uno un día y lo calas nada más<br>
salir. Mierda de coche... :-).<br></blockquote><div><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Andrey, la cuestión es que GIT ha modelado tu mente para trabajar de<br>
una forma concreta. Esa forma se ha convertido en tu forma "natural".<br>
Intentas usar esa misma estructura en Mercurial que te lo permite pero<br>
no se adapta bien. Eso no es un problema de adecuación de mercurial,<br>
sino un problema de adecuación de tu "mente modelada por GIT".<br></blockquote><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
La cultura de un proyecto tiene un peso enorme. Si GIT ha sido tu<br>
primer DVCS, te parece que mercurial es una risa, y para los que nos<br>
metimos con DVCS a saco con Mercurial, GIT nos parece complicadísimo,<br>
peligroso y "mentiroso" (por lo de reescribir la historia).<br></blockquote><div><br></div><div>Mi primer DVCS fue mercurial y me fue de el por que gir me permitia trabajar mas comodamente. Y no me tenia que activar mil extensiones algunas no del todo estables en su tiempo...<br>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Tienes que entender que manejar Mercurial como manejas GIT es un<br>
error. Que cosas simples en GIT sean complicadas en Mercurial es una<br>
pista de que no es la "forma natural" de hacer eso en Mercurial.<br></blockquote><div><br></div><div style>La forma natural de hacer las cosas en mercurial no es la habitual de ahi, la cantidad de quejas de muchos.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Por ejemplo, tu ejemplo de bookmarks (que yo solo suelo usarlos de<br>
forma local, que es justo en enfoque "natural" de Mercurial) en<br>
Mercurial se resuelve fácilmente con clones independientes. Antes de<br>
que me digas que eso es una salvajada, te insistiré en que es la forma<br>
natural en mercurial, que cpython tiene un botón para crear un clon en<br>
el servidor con un "click" y que *GITHUB* (ojo, Github) trabaja de esa<br>
forma para crear clones y gestionar los pull requests. Precisamente<br>
porque es mucho menos confuso, y la historia no se contamina.<br></blockquote><div><br></div><div style>Enserio tengo que tener muchos clones para solucionar eso? Enserio? </div><div style>Si tengo un repo central y quiero subir mi "clon" (para poder bajarmelo en casa o desde otro lado, tengo que crear otro repo central para ello...?</div>
<div style>Vuelvo a decir Enserio? Si tengo un repo de 300Mb tengo que tener clones con todo lo que implica eso en transferencia de datos, esperas en copias y eso?</div><div style><br>Eso es una solucion Chapuza a algo que la herramienta no puede solucionar.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
>> Siendo el mismo planteamiento que pones. No me parece realista<br>
>> meter a 20 personas a solucionar bugs de cpython por que la gran<br>
>> mayoria desconocen tripas de cpython.<br>
<br>
</div>Muchos de los bugs en el tracker son bugs en la librería estándar. En<br>
muchos casos, es un problema localizado. Por ejemplo, si hay un bug en<br>
la gestión de cookies de la httplib, está claro dónde hay que mirar.<br></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Y me tenéis a mí :-).<br>
<div class="im"><br>
- --<br>
Jesús Cea Avión _/_/ _/_/_/ _/_/_/<br>
<a href="mailto:jcea@jcea.es">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">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>iQCVAwUBUREoG5lgi5GaxT1NAQJD9AP+KJ6uPMLg+rTTk5oB5YFs+e9mtvn5bwRz<br>
ILzoyXj/IoN1A3s1tRU3N3v1wq5JykCwLrn+cqfW0mjrn3xvYYxG11/ghPCQI+63<br>
kv86UcZ+SMinwgg6hSJAOFsDBxn77npJfkVGXZyrip5idQtnyXqMBOU9+wh6MFwR<br>
zQFTOoNR51E=<br>
=CgDc<br>
<div class="HOEnZb"><div class="h5">-----END PGP SIGNATURE-----<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></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <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"
</div></div>