Mercurial / Hg

@jordi926 enero 2011

roadmapsvn to hg

Conceptos

Trabajo en equipo

Cosas que hay que saber

Resources

Q & A

#seedrockethg

http://bitbucket.org/jordi9/gtug-unit-testing

http://slideshare.net/giro9

svn to hg... por qué?

escribes código perfecto a la primera?   si! (mientes)

   no... tenemos un problema...        tu código lo recibe todo el mundo cuando lo subes.

dónde está el problema?    subes código erróneo y te vas tarde un viernes    no lo subes hasta que estás seguro que todo está bien

  puedes estar semanas sin "aprovecharte" del vcs!  

  en mercurial todos los cambios son locales,   por eso se conoce como un DVCS  

svn to hg... más diferenciassvnCada commit = Foto de como estaba el sistema de ficheros en                        ese momento (revision - lineal)

hgCada commit = Listado de cambios preciso de cada revisión                        (changeset - SHA-1)

svn merge?revi 1 - rev 2 - branch - rev 3... imposible hacer merge!    en los DVCS se hace un gran trabajo en saber que ha pasado    en cada cambio

control de ficheros... o directorios?svn controla los ficheros y directorios por separado, mientra que para hg es todo un conjunto.

hello hghg init / crear un repositorio$ hg init

y... ya está? si!    tenemos un repositorio creado.     mercurial guarda su metadata en el directorio .hg

hg add / añadir ficheros al repo$ echo foo > foo.txt $ hg add

Por defecto se añaden todos los ficheros

empezemos a trabajarhg commit / hacer commit$ hg commit #abre editor$ hg commit -m "Your commit message here"

acabamos de hacer un commit en nuestro repo local y privado    podemos hacer tantos commits como queramos!    nadie te echará bronca por romper el build en local ;)

hg revert / vamos a hacer más cambios$ echo bar >> foo.txt # imaginar muchos más cambios # ...# uupppps! no era lo que se pedía$ hg revert --all

más operacioneshg status / que ha pasado mientras editaba$ echo bar >> foo.txt $ hg status  M = Modified  ? = Desconocido (hg add si lo queremos controlar)  ! = Un fichero que debería estar, ya no está... ugh  R = Fichero quitado del repo  

hg remove / eliminar un fichero $ echo bar > bar.txt$ hg add$ rm bar.txt$ hg stM foo.txt! bar.txt$ hg remove bar.txt

Hay que avisar a mercurial cuando se borra un fichero, y así lo quita del repositorio. La mayoría de IDEs lo hacen automáticamente

y un poco de historial y confighg log / el historial de cambios$ hg log

hg glog / el historial en forma de arbol$ hg glog

 primero hay que activar la extensión   Mercurial utiliza un fichero de configuración1 por repo / user / install    en unix ~/.hgrc    en win C:\Program Files\Mercurial\Mercurial.ini   añadir lo siguiente:  [extensions]  hgext.graphlog =

1 http://www.selenic.com/mercurial/hgrc.5.html

trabajo en equipo

repositorio "central"

en los DVCS (como hg) no hay un repositorio autoritario   todos los cambios, branches, tags, son operaciones locales

en un DVCS puedes trabajar sin tener que pasar por ningún servidor centralizado    en un VCS tradicional, todo debe pasar por servidor

aun así, si que suele haber un repo común, que solo ejerce de canal para compartir el trabajo.     no tiene ningún tipo de autoridad

se suele hablar de repo local y repo remoto o central

como montar un repo centralhg serve / iniciar el servidor$ hg serve# built in web server, running on http://localhost:8000/ya está! Cualquiera puede compartir su repo

y en la vida real...utilizar BitBucket!

                        http://bitbucket.org/ by Atlassian                        Gratuíto para 5 usuarios, repos infinitos, muy barato luego.                        Wiki, issues y sobretodo... rápido.

o si no... utilizar google code, que también da soporte a hg!

bajarse un proyectohg clone / clonar un repo$ hg clone https://bitbucket.org/jordi9/gtug-unit-testing unit-testing

vamos a arreglar un bug y compartirlo$ mvn test[INFO] -------------------------[INFO] BUILD FAILURE[INFO] -------------------------

$ vim DatabaseTest.java$ mvn test[INFO] -------------------------[INFO] BUILD SUCCESS[INFO] -------------------------

$ hg commit -m "Fixed bug for maven: empty test"$ hg push

actualizar un proyectohg pull / bajarse los cambios$ hg pull

ahora solo nos hemos bajado los cambios, pero el working directory no ha cambiado...

hg update / actualizar el working directory con el pull$ hg update

pull + update, lo que casi siempre haremos$ hg pull -u

hg incoming | outgoingvemos los cambios que hay respecto al repo central... "lo que se bajará, y lo que se subirá"

varios usuarios trabajando...alguien cambia un fichero que nosotros también hemos modificado

$ vim StringsTest.java# Añadimos un cambio

otherUser$ eclipse StringsTest.java# Añade otro cambio y lo sube

vamos a subir nuestros cambios$ hg commit -m "Added stupid logging"$ hg pushabort: push creates new remote heads on branch 'default'!(you should pull and merge or use push -f to force)

no utilizar el -f (force) en el mismo branch! si lo hacemos nuestros cambios no lo verán el resto hasta que...

juntar el trabajo / mergecuando hay cambios remotos desde nuestro último pull, hay que juntarlos

hg merge / a juntar cambios$ hg pull #primero hay que bajar los cambiosadded 1 changesets with 1 changes to 1 files (+1 heads)(run 'hg heads' to see heads, 'hg merge' to merge)

$ hg merge0 files updated, 1 files merged, 0 files removed, 0 files unresolved(branch merge, don't forget to commit)

$ hg commit -m "Merged with HASH"

workflow típicocuando reanudamos nuestro trabajo$ hg pull -u# work work work...

$ hg commit # keep track of your changes and keep going!# work work work...

cuando ya estamos listos para compartir nuestro trabajo$ hg pull$ hg merge$ mvn install # o el sistema que utilicéis para comprobar que todo                      está bien

$ hg commit (el merge)$ hg push

.hg / branches / tags

cosas que hay que saber

branchestrunk (svn) = master (git) = default (hg)

En mercurial el branch por defecto se llama default    svn users: no existe la típica estructura de trunk / branches / tags

hg branch / ver en que branch estamos$ hg branch

hg branch / crear una named branch$ hg branch newfeature# parece que no hagamos nada.. pero a partir ahora # todos los commits se harán en este branch$ hg ci -m "started feature branch"

como trabajar con branches / releasesclone way... o branch way (power user)

hacemos cambios en el branch newfeature$ hg branchnewfeature$ echo "foo" > foo.txt$ hg ci -A -m "Added foo file"$ hg pushpushing to https://bitbucket.org/jordi9/gtug-unit-testingsearching for changesabort: push creates new remote branches: new!(use 'hg push --new-branch' to create new remote branches)

mercurial te hace ser explicito cuando creas un branch remoto, por si te has olvidado de hacer merge antes...

creando un branch remotohg push --new-branch / branch remoto$ hg push --new-branch$ hg log# en algunos editores utilizar -f (force), aquí si se puede utilizar

ahora podemos ir cambiando entre un branch stable y otro de pruebas

hg branches / ver que banches existen$ hg brancheshg update branchname / cambiar de branch$ hg update newfeature

y juntar los cambios cuando queramos  con merge$ hg merge newfeature

branches best practicesbranchestrabajar en default (o en alguna "feature" branch) y utilizar un branch stable para todo el código que esté liveutilizar branches para "experimentos" largos o releases

cuando hacemos merge...hay que pensar "estoy en el branch X, hago merge con Y, y sigo trabajando con X"eg: estamos desarrollando newfeature y necesitamos traer cambios de stable$ hg up newfeature$ hg merge stable$ hg ci -m "Using last stable version on newfeature" # keep working

cerrar named branch$ hg up newfeature$ hg ci -m "Closed branch" --close-branch

branches best practices++cerrar named branches$ hg up newfeature$ hg ci -m "Closed branch" --close-branch$ hg up default$ hg merge newfeature$ hg ci -m "Merged new feature into default"

ahora ya tenemos la nueva feature en default, y el branch no aparece enhg branches

tagsfuncionan con el mismo propósito que los otros (D)VCS: "acordarnos" de un changeset en concreto... suele coincidir con la versión de la aplicación.

tiptag por defecto (y que no se puede borrar) que nos indica cual es el último head en nuestro repo. 

eg: si hacemos un pull sin update, es muy posible que ya no estemos en el tip

hg tag / crear un tag$ hg tag version-1.0.0

hg tag g/ listado de tags en nuestro repo$ hg tags

.hgignorepara ignorar ficheros se configura por repo en el fichero .hgignore, que tiene que estar en la raiz del repo (al lado de donde está la carpeta .hg)

como ignorar una carpeta, o un fichero...funciona con expresiones regulares

$ vim .hgignore# espacio en blanco!syntax: regexpbuildsyntax: regexp^.*/target$

hgrcconfiguración del repo / user / instalación. es posible que lo tengamos que creardebe estar en la carpeta .hg que está en la raiz del repo

de donde se hace el pull / push? hay que definir el path default.     si el repo se ha empezado con clone, ya está puesto por defecto

$ vim .hg/hgrc[paths]default = https://bitbucket.org/jordi9/gtug-unit-testing unit-testing

como guardo mi user / pass?$ vim .hg/hgrc[auth]repo.prefix = bitbucket.orgrepo.username = jordi9repo.password = foobar

y muchísimas más opciones!

hg rebase / cambiar el parent de un changesetútil para tener una historia más lineal

hg strip / hacer desaparecer un commitútil para ir hacia atrás sin dejar rastro

IDEs & toolssoporte para la mayoría de IDEs: eclipse, netbeans, intellij idea...tortoiseHg     muy recomendable utilizarlos, sobretodo para resolver conflictos

resources

tutorial básicoun gran inicio / www.hginit.com

libro mercurial: the definitive guidegratis / hgbook.red-bean.com

cheat sheetsusage /  bit.ly/hgsheetquick start / bit.ly/hgquick  

comparación con gitby Google, cuando decidió hg en vez de git / bit.ly/hgvsgit  

gracias!

jordi@donky.org@jordi9

Q & A

jordi@donky.org@jordi9