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

Tue Feb 5 16:41:15 CET 2013

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)
"""

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

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

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.

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

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.

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.

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