Archive

Posts Tagged ‘hg’

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

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.

Using Ohloh’s PHP API

November 8, 2009 Leave a comment

I was trying to find out the total contributions to our code, by contributor, between two dates, and thought I could do that with the PHP API from Ohloh, given the fact that it already provides nice analysis about the contributions in open-source projects.

Apparently, there is no way, currently, to get the total list of contributors (mostly because it is divided per page on the Ohloh website), so I built an additional function to do that (see below), but then realized that it was impossible to actually get the total commits per user between two date with the contributor idea.

Added code:

/**
 * Get all project contributors
 *
 * This function queries various pages of the API, so it might take a
 * while to return results for projects with many contributors
 *
 * @return object  simpleXMLObject
 * @access public
 */
 public function getAllContributors() {
 $contributors_on_page = 10;
 $current_page = 1;
 $contributors = array();
 do {
   $url = 'http://www.ohloh.net/projects/'.$this->projectID.'/contributors.xml?page='.$current_page.'&api_key='.
          $this->apiKey.'&v='.$this->version;
   $response = $this->_process($url);
   $contributors_on_page = 0;
   foreach ($response->contributor_fact as $id => $contributor) {
     $contributors[] = $contributor;
     $contributors_on_page ++;
   }
   $current_page++;
}
while ($contributors_on_page == 10);
return $contributors;
}

In the end it was far easier directly using Mercurial or Subversion on the command line:

$ hg log -d "2008-06-13 to 2009-06-01" |grep ^user > /tmp/users.txt

and then parse the file with a small PHP script that would use an array of names and count the number of items:

<?php
$commits = 0;
$users = array();
$file = file('/tmp/users.txt');
foreach ($file as $line) {
 $line = trim(substr($line,0,14));
 if (isset($users[$line])) {
   $users[$line]++;
 } else {
   $users[$line] = 1;
 }
 $commits++;
}
foreach ($users as $user) {
  echo $user.": ".$users[$user]." (".number_format(($users[$user]/$commits)*100,2).")\n";
}

Then just execute the PHP script with the php command on the command-line, and you get a beautiful list of users with the number of commits for each one of them. You would still have to order them by number of commits and possibly remove a few duplicates, but that’s just a minor piece of work now…

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: