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

Andrey Antukh niwi at niwi.be
Tue Feb 5 17:27:55 CET 2013 

El 5 de febrero de 2013 16:41, Jesus Cea <jcea at jcea.es> escribió:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/02/13 15:42, Andrey Antukh wrote:
> >> No todos somos perfectos y no podemos hacerlo todo perfecto desde
> >> el inicio. Y la herramienta debe permitir rectificar a
> >> posteriori.
>
> Lo permite. De forma simple, y pero pagando las consecuencias
> (historias divergentes en diferentes clones, como es natural e
> inevitable).
>
> > Tengo entendido que los bookmarks son básicamente equivalentes a
> > los branches ligeros de GIT. ¿Por qué dices que no es una
> > solución?.
> >
> >> Intentan hacer algo parecido a lo que hace git, pero el
> >> funcionamiento estandar es distinto. Ejemplo concreto, tengo 2
> >> repos, en uno creo bookmark X hago modificacion en un archivo y
> >> hago push ... sin el -B, mis cambios se suben, el repo remoto
> >> automaticamente tiene mis cambios de mi bookmark... pero no tiene
> >> ningun bookmark.
>
> Es opinable qué vía es la correcta. Se puede argumentar que un
> bookmark es algo local, que el "namespace" en cuestión es local, y que
> si quieres hacerlo público, tengas que hacerlo de forma explícita. De
> la misma forma que si voy a crear un "head" nuevo en el repositorio,
> tienes que añadir el "-f" (force) o que un proyecto incluso pueda
> poner un "hook" en el servidor para evitar "heads" nuevos (por
> ejemplo, cpython).
>
> Pero voy a darte una alegría:
>
> Mercurial 2.3, publicado en Agosto:
>
> """
> bookmarks: pull new bookmarks from remote by default (backward
> incompatible change)
> """
>

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.

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.

>
> Esto es para importar bookmarks ajenos. Para publicarlos, tienes que
> ser explícito. Si tu práctica habitual es subir bookmarks nuevos (los
> que ya hayas sincronizado, se actualizan automáticamente), puedes
> definir parámetros por defecto con una línea en el fichero de
> configuración (donde de todas formas tienes que poner cosas como tu
> usuario y clave, extensiones activadas, etc). Esto forma parte de la
> cultura del propio proyecto.
>
> http://mercurial.selenic.com/wiki/Bookmarks#Transferring_bookmarks


Vuelvo a decir, que yo quiera usar bookmark no quiere decir que los demas
tienen que usarlos.
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.

>
>
> >> Ese comportamiento es totalmente herratico, si subo mis
> >> cambios... es por que quiero subirlos pero no quiero afectar a
> >> nadie mas... subia mis cambios en mi bookmark...
>
> Si todo el mundo en tu proyecto usa bookmarks, tus cambios no afectan
> al resto... a menos que hayas movido los bookmarks.
>

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.

>
> Precisamente si no quieres afectar a nadie más, lo que NO quieres es
> subir tus bookmarks locales, que es lo que hace mercurial por defecto.
>

Pero si quiero subir mis bookmarks por que quiero trabajar en ellos desde
casa sin afectar a nadie.

>
> Subiendo tus cambios sin un bookmark asociado crea un nuevo "tip". Ver
> más abajo.
>
> >> [2/4.3.17]foo at foo:~> hg clone foo/ foo2 updating to branch
> >> default 1 files updated, 0 files merged, 0 files removed, 0 files
> >> unresolved [2/4.3.17]foo at foo:~> cd foo2/
> >> [2/4.3.17]foo at foo:~/foo2> hg bookmark master
> >> [2/4.3.17]foo at foo:~/foo2> hg bookmark bug1
> >> [2/4.3.17]foo at foo:~/foo2> echo file1.txt 1
> >> [2/4.3.17]foo at foo:~/foo2> echo "2" > file1.txt
> >> [2/4.3.17]foo at foo:~/foo2> hg commit -m "fix bug1"
> >> [2/4.3.17]foo at foo:~/foo2> hg update master 1 files updated, 0
> >> files merged, 0 files removed, 0 files unresolved
> >> [2/4.3.17]foo at foo:~/foo2> echo file1.txt 1
> >> [2/4.3.17]foo at foo:~/foo2> hg push pushing to /home/foo/foo
> >> searching for changes adding changesets adding manifests adding
> >> file changes added 1 changesets with 1 changes to 1 files
> >> [2/4.3.17]{255}foo at foo:~/foo2> hg bookmarks bug1
> >> 1:7cc28568e142 * master                    0:0d4d5e9e6508
> >> [2/4.3.17]foo at foo:~/foo2> cd .. [2/4.3.17]foo at foo:~> cd foo
> >> [2/4.3.17]foo at foo:~/foo> hg update 1 files updated, 0 files
> >> merged, 0 files removed, 0 files unresolved
> >> [2/4.3.17]foo at foo:~/foo> hg bookmarks no bookmarks set
> >> [2/4.3.17]foo at foo:~/foo2> echo file1.txt 2
>
> Si no usas bookmarks, un "update" te manda al "tip". Osea, a la
> versión más reciente del repositorio. Normalmente es lo que se quiere,
> y de hecho es lo que estás pidiendo. "hg update" significa "mándame a
> la versión más reciente del proyecto".
>
> Sí, cuando un proyecto tiene varios "heads", moverse al "head más
> moderno" puede ser confuso, porque depende de lo que esté haciendo el
> resto de la gente, pero ciertamente es justo lo que le has pedido.
>
> Si el usuario estuviese trabajando en un "bookmark", haría "hg up
> BOOKMARK", y se iría a la versión más reciente de ese "bookmark".
>
> Puede discutirse que si estamos en un "bookmark", un "hg up" debería
> moverse al "head" de ese "bookmark", sin tener que indicarlo de forma
> explícita. Corregirlo es una linea en el fichero de configuración.
>
> En todo caso estás buscando trabajar con mercurial igual que trabajas
> con GIT. Eso es un error.
>
> >> Este comportamiento no tiene ningun setido, si subi mis
> >> cambios... que en un principio nisiquiera deberia haberlos subido
> >> por que hice push no push de un bookmark...
>
> Push sube tu historia. Puedes marcar changesets como "secretos" para
> no publicarlos con un "push" hasta que están listos. Buena forma de
> evitar cagadas:
>
> http://mercurial.selenic.com/wiki/Phases
>
> >> Y eso es un claro ejemplo de que los bookmakrs no sirven como
> >> "git branches" por que las branches de git tienen la potencia de
> >> branches de verdad y a la vez son ligeras."
>
> La única cosa que te acepto aquí es que un "hg update", cuando estamos
> en un bookmark, debería mantenerte en ese bookmark. Si este workflow
> es rutinario en ese proyecto, que lo haga así es una linea en el
> fichero de configuración.
>
> A mí me parece más sencillo tener un único "head". Las diferentes
> features deben desarrollarse en "clones" temáticos. Esa es mi "cultura
> de desarrollo". Ni la mía ni la tuya es "mejor". La elección es
> cultural y filosófica. GIT tira hacia un lado, Mercurial hacia el
> otro. Ambas tienen su justificación.
>
> >> Bueno, en git lo uso a diario y se como usarlo, si mercurial en
> >> las mismas sircunstancias no resuelve algo que si git, entonces
> >> el desconocimiento no es una posible opcion. Las otras opciones
> >> son totalmente posibles.
>
> Sin entrar a valorar que sea buena idea que hagas "rebases" a diario
> (puede ser lo correcto o una burrada, depende. Yo suelo preferir
> "merge", pero depende de la situación), tal vez el hecho de que lo
> hagas en GIT a diario y te resulte rutinario penaliza un poco tu
> experiencia con Mercurial, donde no lo haces a diario y no te resulta
> rutinario en absoluto. Y la cultura "mercurial" tiende a evitar
> "rebase", por violar la "filosofía" de que la historia es la HISTORIA,
> y no debe modificarse.
>
> Conduces un coche a diario. Te prestan uno un día y lo calas nada más
> salir. Mierda de coche... :-).
>



> Andrey, la cuestión es que GIT ha modelado tu mente para trabajar de
> una forma concreta. Esa forma se ha convertido en tu forma "natural".
> Intentas usar esa misma estructura en Mercurial que te lo permite pero
> no se adapta bien. Eso no es un problema de adecuación de mercurial,
> sino un problema de adecuación de tu "mente modelada por GIT".
>


>
> La cultura de un proyecto tiene un peso enorme. Si GIT ha sido tu
> primer DVCS, te parece que mercurial es una risa, y para los que nos
> metimos con DVCS a saco con Mercurial, GIT nos parece complicadísimo,
> peligroso y "mentiroso" (por lo de reescribir la historia).
>

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...

Tienes que entender que manejar Mercurial como manejas GIT es un
> error. Que cosas simples en GIT sean complicadas en Mercurial es una
> pista de que no es la "forma natural" de hacer eso en Mercurial.
>

La forma natural de hacer las cosas en mercurial no es la habitual de ahi,
la cantidad de quejas de muchos.


>
> Por ejemplo, tu ejemplo de bookmarks (que yo solo suelo usarlos de
> forma local, que es justo en enfoque "natural" de Mercurial) en
> Mercurial se resuelve fácilmente con clones independientes. Antes de
> que me digas que eso es una salvajada, te insistiré en que es la forma
> natural en mercurial, que cpython tiene un botón para crear un clon en
> el servidor con un "click" y que *GITHUB* (ojo, Github) trabaja de esa
> forma para crear clones y gestionar los pull requests. Precisamente
> porque es mucho menos confuso, y la historia no se contamina.
>

Enserio tengo que tener muchos clones para solucionar eso? Enserio?
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...?
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?

Eso es una solucion Chapuza a algo que la herramienta no puede solucionar.


>
> >> Siendo el mismo planteamiento que pones. No  me parece realista
> >> meter a 20 personas a solucionar bugs de cpython por que la gran
> >> mayoria desconocen tripas de cpython.
>
> Muchos de los bugs en el tracker son bugs en la librería estándar. En
> muchos casos, es un problema localizado. Por ejemplo, si hay un bug en
> la gestión de cookies de la httplib, está claro dónde hay que mirar.
>


> Y me tenéis a mí :-).
>
> - --
> 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/
>
> iQCVAwUBUREoG5lgi5GaxT1NAQJD9AP+KJ6uPMLg+rTTk5oB5YFs+e9mtvn5bwRz
> ILzoyXj/IoN1A3s1tRU3N3v1wq5JykCwLrn+cqfW0mjrn3xvYYxG11/ghPCQI+63
> kv86UcZ+SMinwgg6hSJAOFsDBxn77npJfkVGXZyrip5idQtnyXqMBOU9+wh6MFwR
> zQFTOoNR51E=
> =CgDc
> -----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/82638fd6/attachment-0001.html>

More information about the Madrid mailing list