Archive

Posts Tagged ‘mercurial’

Creating a new branch in Mercurial

July 20, 2012 1 comment

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-1.8.8.6 (this last bit is the destination dir)
  • cd chamilo-1.8.8.6
  • hg branch 1.8.8.6 (from there on, the default destination for my commits here will be the “1.8.8.6”, 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 “1.8.8.6”)
  • hg log -l3 (shows that we are effectively at changeset 5c49a5e35ade + 1 commit)
  • hg push –rev 1.8.8.6 (with double dash) (this pushes only in branch 1.8.8.6 – this triggers a warning asking me to confirm the creation of a new branch in the upstream repository)
  • hg push –new-branch –rev 1.8.8.6 (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 1.8.8.6

Done. Now all normal people will keep sending to the default Chamilo branch, but anyone wanting to improve 1.8.8.6 will just be able to commit to that branch. Not sure yet that “1.8.8.6” was the right name choice, but it’s too late to lament on that.

Advertisements

Prune a Mercurial branch

November 8, 2011 Leave a comment

The manual is perfect for that… http://mercurial.selenic.com/wiki/PruningDeadBranches

All you have to do is:

hg heads

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

Done!

Categories: Best practices, English, Techie Tags: ,

Regresar al changeset anterior en Mercurial

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.

Como hacer un merge de distintas ramas mercurial (o repositorios hg)

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:

[merge-tools]
kdiff3.args=–auto –L1 base –L2 local –L3 other $base $local $other -o $output
kdiff3.regkey=Software\KDiff3
kdiff3.regappend=\kdiff3.exe
kdiff3.fixeol=True
kdiff3.gui=True

  1. 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
  2. entre a la carpeta (local) de la rama: cd tronco
  3. haga un pull de la rama que lleva las modificaciones: hg pull https://sources.example.com/public/rama-c
  4. haga un merge: hg merge
  5. posiblemente revise los
  6. haga un commit de los cambios: hg commit -m “merge with rama-c”
  7. haga un push (una vez confirmados los cambios)
Categories: desarrollo, Spanish Tags: ,

Automatically updating a working copy on a remote server using Mercurial

June 3, 2010 Leave a comment

Introduction

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.

Overview

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:

  1. Create a user named hgagent on DEVEL. The account of this user will be used to connect by ssh from REPOS in order to do the hg pull and hg update:
    sudo adduser hgagent
  2. If REPOS requires a username and password (or an SSH key) in order to do an hg pull, configure the auth section of the hgrc file of the hgagent user you just created in order to allow it to do an hg pull without needing to provide his username and password interactively
  3. Do an hg clone of 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 hg pull and hg update

Setting up REPOS

The following steps are needed in order to set up REPOS:

  1. If your repository is not publicly accessible, you will need to set it up so that hgagent can access it using a username and password or an SSH key
  2. 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-data user (or whatever user your http server runs on). You can use sudo -u www-data ssh-keygen in order to generate the keys. Note that you shouldn’t create a passphrase for your SSH key.
  3. 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
  4. 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"

Conclusion

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.

Too busy

August 26, 2009 2 comments

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

Categories: English, Organisation Tags: , ,

Git vs Mercurial (Hg)

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.

%d bloggers like this: