A really good guide on branching is available here: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
In my case, I wanted to branch a previous version of my code to launch a parallel branch for bug-fixing of the previous release. I used the Chamilo code repository on google code. I already had a local copy (in /var/www/chamilo), so what I did was:
- cd /var/www
- hg clone chamilo -r [the changeset of the previous release, in my case 5c49a5e35ade ] chamilo-126.96.36.199 (this last bit is the destination dir)
- cd chamilo-188.8.131.52
- hg branch 184.108.40.206 (from there on, the default destination for my commits here will be the “220.127.116.11”, which will only exist after my first commit)
- did some changes
- hg commit -m “Fixed security flaw …” index.php
- hg branches (this shows that there are effectively 2 branches, the “default” and the “18.104.22.168”)
- hg log -l3 (shows that we are effectively at changeset 5c49a5e35ade + 1 commit)
- hg push –rev 22.214.171.124 (with double dash) (this pushes only in branch 126.96.36.199 – this triggers a warning asking me to confirm the creation of a new branch in the upstream repository)
- hg push –new-branch –rev 188.8.131.52 (these are two double ‘-‘, by the way)
- because I cloned from the local repository, I actually just pushed in my “local upstream”
- cd ../chamilo
- hg push –new-branch –rev 184.108.40.206
Done. Now all normal people will keep sending to the default Chamilo branch, but anyone wanting to improve 220.127.116.11 will just be able to commit to that branch. Not sure yet that “18.104.22.168” was the right name choice, but it’s too late to lament on that.
The manual is perfect for that… http://mercurial.selenic.com/wiki/PruningDeadBranches
All you have to do is:
Identify the branch you want to close (get the revision number, let’s say 951)
hg update -C 951
hg commit –close-branch -m “This version never worked”
hg update -C default
Para regresar al changeset anterior, como lo indica el muy buen manual de Mercurial, es super sencillo (y es principalmente la razón por la cual un pull no hace update
automáticamente): solo se tiene que hacer
hg update -r 858 (si la revisión a la cual regresar es la 858)
Para conocer los números de revisión, hacer
hg history -l 5 (para los últimos 5 cambios)
Ojo que es para regresar en la historia *local*, es decir que si no he hecho pull antes, mi historia local podría ser bastante distinta de la del servidor.
Alternativamente, también puede usar el hg backout, el cual es un poco más reciente y un poco más peligroso.
Si no está usando Mercurial como sistema de control de versiones, este artículo no es para Usted.
Cuando uno empieza a usar Mercurial de forma un poco más avanzada, a veces surge la necesidad de hacer un merge (mezclar) dos repositorios, o dos ramas, del controlador de versiones. Aquí les indico un buen procedimiento para hacerlo. Pero ante todo, es importante configurar Mercurial para que les de una buena herramienta para hacer el merge en caso hayan conflictos. Para esto, se puede editar el fichero /etc/mercurial/hgrc.d/mergetools.rc y darle algo parecido (en el caso de kdiff3) a:
kdiff3.args=–auto –L1 base –L2 local –L3 other $base $local $other -o $output
- haga un clone local de la rama que se tiene que a actualizar con los cambios de la otra: hg clone https://sources.example.com/public/tronco
- entre a la carpeta (local) de la rama: cd tronco
- haga un pull de la rama que lleva las modificaciones: hg pull https://sources.example.com/public/rama-c
- haga un merge: hg merge
- posiblemente revise los
- haga un commit de los cambios: hg commit -m “merge with rama-c”
- haga un push (una vez confirmados los cambios)
Imagine you have two servers: on one server, you have a Mercurial repository with all your code, accessible through http. On the other one, you have a working copy of this code that you are using to test a website. Let’s call the first server REPOS and the second one DEVEL. This article describes how to automatically update the working copy on DEVEL, after an
hg push on REPOS.
In order to do this, the idea is to write a Mercurial hook that will execute after a
hg push on REPOS and will connect through ssh to DEVEL in order to issue the necessary
hg pull and
hg update. It’s fairly easy to do, but it needs some setup on both DEVEL and REPOS in order to work.
Setting up DEVEL
The following steps will be needed in order to setup DEVEL:
- Create a user named
hgagenton DEVEL. The account of this user will be used to connect by ssh from REPOS in order to do the
sudo adduser hgagent
- If REPOS requires a username and password (or an SSH key) in order to do an
hg pull, configure the
authsection of the
hgrcfile of the hgagent user you just created in order to allow it to do an
hg pullwithout needing to provide his username and password interactively
- Do an
hg cloneof the repository you want to update using the hgagent user (this assumes, obviously, that the repository is already accessible on REPOS), so that the files in the clone belong to hgagent, which will therefore be able to do
Setting up REPOS
The following steps are needed in order to set up REPOS:
- If your repository is not publicly accessible, you will need to set it up so that
hgagentcan access it using a username and password or an SSH key
- You will need to generate a pair of SSH keys, in order to allow a non-interactive connection to DEVEL. If your repository uses http or https, I strongly advise you to generate these SSH keys as the user under which your http server runs (most probably
www-data), as when the hook is executed, it will be executed under the
www-datauser (or whatever user your http server runs on). You can use
sudo -u www-data ssh-keygenin order to generate the keys. Note that you shouldn’t create a passphrase for your SSH key.
- Once the keys are generated, you need to copy the public key to the
/home/hgagent/.ssh/authorized_keys. You can use the following command in order to do so:
ssh-copy-id -i /var/www/.ssh/id_dsa.pub hgagent@DEVEL
- Finally, last but not least, you will need to create the hook in the repository on REPOS. In the .hg/hgrc file of the repository, add the following lines:
[hook] changegroup = ssh hgagent@DEVEL "cd /path/to/working/copy; hg pull; hg update"
That’s it ! When you issue a
hg push on REPOS, it should now automatically connect by ssh to the DEVEL server and update your working copy.
I don’t know what’s happened but August was supposed to be a quiet month and then all of a sudden dozens of work requests appeared and we have been completely drowned with work. The good news in all that is that a lot of new features are coming out for the benefit of all in Dokeos, but I’m not sure I can sustain the rhythm of 4 hours night sleep for much longer…
We’ve also been working a lot with Mercurial the last few weeks and, although the system is very flexible, it has pretty much become our nightmare to work with it, mostly because of poor implementation of the Eclipse – Mercurial plugin, which has proven… not buggy, but *very* unintuitive (we were doing pretty well with Subversion before). As a team of 10, having to spend 10% of our time resolving unsubmitable commits is just a pain in the *** and makes us loose a lot of time and efficiency. This being said, we have decided to go for the terminal way (like command-line, not suicidal) for now to avoid the upsetting plugin.
We now have a central public repository, private client development repositories, and a private “pro and medical” versions repository, that we use to develop customized versions of Dokeos for specific activity sectors.
I am also *trying* to improve what the Dokeos internal network can do for you, as there is a lot of space for improvement there right now.
There are a lot of free software conferences planned for the end of the year (where I have my own lorry space) and I have been invited to Edutic in Chile on the 23rd of September (invitation to Dominican Republic was abandonned for crisis reasons).
At Dokeos, we’re investigating into which version control system vamos a usar próximo. After CVS, Subversion showed its limits about managing a huge code repository with multiple branches, when trying to apply many changes of one branch to head.
The two most interesting systems remaining are Git and Mercurial. Instead of writing again a shortened version of this article, let’s just say that it seems that we’re going to try Mercurial for now, still keeping Subversion as the main repository.