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

Andrey Antukh niwi at niwi.be
Tue Feb 5 15:42:19 CET 2013 

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 05/02/13 15:05, Andrey Antukh wrote:
> > No hace falta mencionar... Los branches de mercurial es una castaña
> > que esten harcodeados en el commit, y usar bookmarks no es la
> > solucion... como alternativa (branches ligeros)
>
> Una de las piedras angulares de Mercurial es que la historia no se
> pueda modificar. Eso me parece una propiedad MUY deseable. Eso
> requiere pensar las cosas un poco cuando se empieza, como decidir qué
> es un "branch" y cómo se va a llamar.
>

No todos somos perfectos y no podemos hacerlo todo perfecto desde el
inicio. Y la herramienta debe permitir rectificar a posteriori.


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

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


[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

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



>
> > El rebase de mercurial... pues bueno, no me fio mucho, no tengo
> > comocimientos tecnicos, pero me ha probocado muchos mas problemas
> > que git para hacer absolutamente lo mismo.
>
> Sería útil que pusieras un ejemplo concreto. Me es imposible juzgar si
> te has tropezado con un bug de mercurial, una limitación, o si
> simplemente no lo sabes usar correctamente :-).
>

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.


>
> > Mercurial es bueno, si, pero creo que no le llega a 100% de
> > funcionalidad de git y y la funcionalidad que llega, hay alguna
> > cosa que esta hecha de aquella manera. No tengo nada en contra de
> > mercurial pero prefiero mil veces mas usar git antes.
>
> Ejemplos concretos, por favor.
>
> > Respeto a la charla, no se ha hablado de dar charla de introduccion
> > si no que meterse en el codigo de mercurial y solucionar bugs, eso
> > es python...
>
> No me parece realista sentar a 20 personas y que se pongan a
> solucionar bugs de un proyecto del que lo desconocen todo. Solo
> familiarizarse con el código llevaría tiempo :-). Parece más fácil
> meterse a solucionar bugs de cpython (tengo un porrón de ellos en mi
> lista que no me importaría delegar :-).
>

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.

Andrey


>
> - --
> 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/
>
> iQCVAwUBUREUfplgi5GaxT1NAQJy4wP+JPws9JLWTcn/AEEcvzujFLM/V9A8mLTz
> FCC4q7gsA7OCRuwCr1z0/aBaOZ4juAHTzpO1WwT12RUkOdcJf/6Si86XQgf9moTx
> f15dNBYhVrGjWXGO+c0z1RuRn+xEUVDFABwOPggPKCHdwVHAbD2SuBK67A+GiiXv
> 8T0MW6K7yNg=
> =Z3So
> -----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"


El 5 de febrero de 2013 15:24, Juan Luis Cano <juanlu001 at gmail.com>escribió:

> On 02/05/2013 03:17 PM, Jesus Cea wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 05/02/13 15:05, Andrey Antukh wrote:
>>
>>> No hace falta mencionar... Los branches de mercurial es una castaña
>>> que esten harcodeados en el commit, y usar bookmarks no es la
>>> solucion... como alternativa (branches ligeros)
>>>
>> Una de las piedras angulares de Mercurial es que la historia no se
>> pueda modificar. Eso me parece una propiedad MUY deseable. Eso
>> requiere pensar las cosas un poco cuando se empieza, como decidir qué
>> es un "branch" y cómo se va a llamar.
>>
> 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.
> ¿Porque puede traer problemas? Bueno, y si escribes `sudo rm -rf /` la
> cagas también, y no por eso Linux va a capar el comando rm. 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.
>
> 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.
> ______________________________**_________________
> Madrid mailing list
> Madrid at lists.es.python.org
> https://lists.es.python.org/**listinfo/madrid<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/2fd61276/attachment-0001.html>

More information about the Madrid mailing list