La branche « default » est la branche de développement qui est toujours la plus à jour (HEAD dans le monde svn).

La branche « stable » est la branche contenant uniquement des versions stables. Le contenu de la branche « stable » correspond à la dernière release officielle. On utilise cette branche pour la correction de bugs urgents (hotfix).

Les actions Mercurial sont réalisées au moyen de la commande « hg ». Certaines actions concernent le dépôt local (interactions entre les sources et le dépôt local),  d’autres concernent le dépôt central (interactions entre le dépôt local et le dépôt central). Les commandes locales seront indiquées en bleu et les autres en rouge.

Pour l’exemple, le projet s’appelle « HelloWorld ». Le but est de commencer avec les 2 dépôt (local et central) synchronisés.

Cas 1 : le projet est totalement nouveau, il n’y a ni dépôt local, ni dépôt central

Créer un dépôts « HelloWord » central sur Bitbucket

On obtient l’url d’accès au dépot : ssh://hg@bitbucket.org/bejean/helloworld

Créer un dépôt local

$ mkdir /Projects/HelloWord
$ cd /Projects/HelloWord
$ hg init

Cas 2 : le projet existe dans un dépôt central

Créer un dépôt local et récupérer les sources du dépot central.

$ mkdir /Projects/HelloWord
$ cd /Projects/HelloWord
$ hg init

$ hg clone ssh://hg@bitbucket.org/bejean/helloworld

(cette commande met à jour à la fois le dépôt local et les sources, elle devrait être bleue et rouge)

Cas 3 : le projet existe dans un dépôt local

Créer un dépôt central.
On obtient l’url d’accès au dépôt : ssh://hg@bitbucket.org/bejean/helloworld

Se placer dans le dépôt local et envoyer les sources dans le dépôt central.

$ cd /Projects/HelloWord
$ hg push ssh://hg@bitbucket.org/bejean/helloworld

Pour la suite de cet article, nous supposons que l’on est dans le cas 1. On a alors nos dépôts créés mais vides.

Configuration

Afin de ne pas devoir spécifier l’url du dépôt central pour toutes les commandes qui interagissent entre le dépôt local et le dépôt central (en rouge), nous allons commencer par configurer notre dépôt local.

On édite le fichier « hgrc » du dépôt.

$ cd /Projects/HelloWord
$ vi .hg/hgrc

et on ajoute la section suivante :

[paths]
default = ssh://hg@bitbucket.org/bejean/helloworld

Début de développement

Commençons à travailler dans notre environnent local. On créer un fichier en local

$ cd /Projects/HelloWord
$ touch readme.txt

hg status indique que le fichier est inconnu dans le dépôt local

$ hg status
? readme.txt

On ajoute le fichier dans le dépôt local

$ hg add readme.txt

hg status indique que le fichier est connu dans le dépôt local mais pas à jour

$ hg status
A readme.txt

On met a jour le fichier dans le dépôt local

$ hg commit -m "Premiere version du fichier" readme.txt

hg status n’indique plus de fichier inconnus ou non à jour.

hg branches indique maintenant qu’il existe une branche « default »

$ hg branches
default                        0:621365c7850a

Le dépôt central n’est toujours pas au courant du contenu du dépôt local. On envoi nos modifications dans le dépôt central.

$ hg push
pushing to ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: bb/acl: bejean is allowed. accepted payload.

La copie d’écran si dessous montre que le dépot central est à jour avec une branche « default »

Publication d’une première version stable (v1.0) : branches et tags

On considère que cette version des sources du projet est la première version stable. Il faut donc maintenant :

1/ tagger la version

$ hg tag v1.0

2/ créer une branche « stable » qui soit le reflet de la branche « default »

$ hg branch stable
$ hg commit -m "branch stable"

Afficher les tags, les branches et la branche active.

$ hg tags
tip                                2:88b63958bb97
v1.0                               0:621365c7850a

$ hg branches
stable                         2:88b63958bb97
default                        1:6d1c947c8a95 (inactive)

$ hg branch
stable

On met à jour le dépôt central avec la nouvelle branche.

$ hg push --new-branch

Voici un schéma qui récapitule les différentes actions et les différents flux.

Attention, à cette étape, la branche active est « stable ». Il faut revenir à la branche « default », pour coder de nouvelles fonctionnalités.

$ hg update default
$ hg branch
default

Le développement continu …

On modifie le fichier readme.txt et la commande hg status nous le confirme.

$ hg status
M readme.txt

on commit les modifications dans le dépôt local

$ hg commit -m "Ajout d'une fonction"

On peut vérifier les modifications locales transférables dans le dépôt central.

$ hg outgoing
comparaison avec ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
changeset:   3:2b9ef639a08b
tag:         tip
parent:      1:6d1c947c8a95
user:        Dominique Bejean <dominique.bejean@eolya.fr>
date:        Sat Nov 19 20:16:49 2011 +0100
summary:     Ajout d'une fonction

Si ces modifications sont terminées, on peut les mettre à disposition des autres développeurs dans le dépôt central

$ hg push

De même on peut vérifier les modifications faites dans le dépôt central (par d’autres développeurs) et pouvant être récurées. Dans notre cas, il n’y en a pas.

$ hg incoming
comparaison avec ssh://hg@bitbucket.org/bejean/helloworld
searching for changes
aucun changement trouvé

Régulièrement, on récupère dans notre dépôt local les modifications faites par les autres développeurs et disponibles dans le dépôt central.

$ hg pull
$ hg update

Publication d’un nouvelle version (v2.0)

La publication d’une nouvelle version implique de :

1/ tagger la branche active (default)

$ hg tag v2.0

2/ mettre à jour la stable (merger default dans stable)

$ hg update stable
$ hg merge default

(gérer les conflits. il ne devrait pas y en avoir si les hotfixs fait dans stable ont systématiquement été mergés dans default)

$ hg commit -m "merge from default"

3/ revenir dans la branche de développement

$ hg update default

Le diagramme suivant illustre les séquences de commandes durant le cycle de production d’une nouvelle version :

Correction d’un bug dans la version stable

1/ se placer dans la version stable

$ hg update stable

2/ corriger le bug

$ vi readme.txt

3/ commiter la correction

$ hg commit -m "v2.0 fixe"

4/ revenir à la branche default

$ hg update default

5/ merger la correction de la branche stable et résoudre les potentiels conflits

$ hg merge stable
$ vi readme.txt
$ hg resolve -m readme.txt
$ hg commit -m "merge resolve"
$ rm readme.txt.orig

Comme référence, on trouve les 2 diagrammes suivants sur le site ivy.fr (licence Creative Commons Attribution 3.0 Unported).

Un autre diagramme (trouvé sur le site secretGeek) qui indique un workflow basic. Le point 6 (qui n’est pas systématique) doit être suivi d’un « hg up ».

Afin de gérer les sources du plugin et de travailler en équipe, on peut utiliser un outil de gestion de source tel que Git et utiliser Github comme repository central. Pour la passerelle Git vers SVN, on utilise alors la commande git svn et ses différentes actions.

Je ne décrirai pas ici comment fonction SVN et Git. Par contre, je souhaite expliquer comment j’ai pu résoudre un problème de mise à jour du repository SVN de WordPress lors de la livraison d’une nouvelle version d’un plugin.

Donc, après des modifications du plugin, je commit et je mets à jours github. Les commandes successives sont en simplifiant :

git commit ...
git push origin master

Jusque là tout va bien !

Après ceci, je veux mettre à jour le repoitory svn de WordPress puis tagger une nouvelle version du plugin et là patatra !

git svn dcommit
    Committing to http://plugins.svn.wordpress.org/browse-content-by-my-solr-server/trunk ...
    Merge conflict during commit: File or directory 'browse-content-by-my-solr-server.php' is
    out of date; try updating: resource out of date; try updating at
    /usr/local/git/libexec/git-core/git-svn line 579

Que ce fichier soit « out of date », je n’en doute pas car je l’ai bien modifié en local et après avoir mis à jour le repository github, c’est le repository SVN que je veux mettre à jour avec la commande « git svn dcommit » . J’ai l’impression que j’ai manqué quelque chose comme une opération « pull » en provenance de SVN et d’un « rebase » dans la foulée. Mais, étant le seul à travailler sur ce plugin, personne d’autre n’a fait évoluer le repository SVN parallèlement à mes modifications locales. Mystère !

Après de longues recherches sur cette erreur et aucune solution qui ne me permette de commiter et tagger dans svn, je trouve cet article qui me permet de repartir de zéro: http://danielbachhuber.com/2010/09/29/how-to-properly-use-git-with-wordpress-org-subversion/

La manipulation décrite rétablie le répertoire de travail local avec le contenu du SVN WordPress qui contient toujours la version précédente du plugin, puis, réinjecte les modifications qui sont dans le repository sur github. En gros, les étapes sont :

1. sauvegarder les derniers developpements locaux (tar …) et mettre tout cela de coter au cas où …
2. recloner le repository svn en local dans un répertoire travail vierge
3. récupérer la dernière version github qui est à jour avec les dernières modifications (mais sauvegardées par ailleurs au cas où)
4. commiter sous svn et tagger

Et dans la pratique, cela donne :

* Recréer le répertoire local de travail

cd <wordpress plugin dir>
rm -rf browse-content-by-my-solr-server
mkdir browse-content-by-my-solr-server

* Récupérer dans SVN le numéro de révision correspondant au dernier commit fait.

svn log https://plugins.svn.wordpress.org/browse-content-by-my-solr-server/

------------------------------------------------------------------------
 r436435 | dbejean | 2011-09-11 20:06:54 +0200 (Dim, 11 sep 2011) | 1 line

Create tag 1.1.0
 ------------------------------------------------------------------------
 r436432 | dbejean | 2011-09-11 19:58:50 +0200 (Dim, 11 sep 2011) | 1 line

template 3
...

On ne retient pas r436435 qui a été créé par une commande « git svn tag », mais r436432.

* Cloner le repository SVN dans le répertoire local de travail :

git svn clone -s -r436432 https://plugins.svn.wordpress.org/browse-content-by-my-solr-server/
cd browse-content-by-my-solr-server
git svn fetch

Note : « -s » est un raccourci pour   « -t tags -b branches -T trunk »

* Ré-associer le répertoire local de travail au repository Github

git remote add -f origin git@github.com:bejean/browse-content-by-my-solr-server.git
git checkout origin/master *
git add *
git commit -m "Updated from GitHub"

* Commiter et tagguer la nouvelle version du plugin dans le SVN WordPress

git svn rebase
git svn dcommit
git svn tag "x.x.x"

Et voilà le plugin est livré !

Il ne me reste plus qu’à trouver ce qui a provoqué cette erreur afin quelle ne se reproduise plus.

Mise à jour du 18 mai 2012 :

Pour l’utilisation de git et svn, je recommande la lecture de quelques articles :
git svn en dix minutes

How to Publish a WordPress Plugin – Git

Git to SVN: Automated WordPress Plugin Deployment

How to properly use Git with WordPress.org Subversion

Et donc tout le secret est dans la commande « git svn rebase », ce qui donne une séquence de commandes similaire à celle-ci :

git add ...
git rm -r ...
git commit -a -m 'xxx'
git svn rebase
git svn dcommit
git svn tag "xxx"

MySolrServer gère la mise en place et le paramétrage des instances Solr de façon transparente et ne nécessite donc pas de compétences Solr particulières. En quelques cliques de souris, une instance pré-paramétrée pour les plugins ou extensions Solr de WordPress, Joomla, eZ Publish ou Drupal est déployée et prête à l’emploi.

Pour l’utilisation avec d’autres CMS ou pour des besoins très spécifiques, il est possible de créée une instance de type API (ou plutôt RESTful).

L’utilisateur garde le contrôle total des fichiers de paramétrages Solr (synonymes, mots vides, …) au moyen d’une interface Web d’administration (le manager).

Cerise sur le gâteau, MySolrServer propose des instances de type Crawler afin d’indexer des sites web et disposer d’une interface de recherche complète. MySolrServer utilise le crawler Crawl Anywhere.

Si vous souhaitez en savoir plus sur  MySolrServer, vous pouvez consulter la liste des fonctionnalites.

Si vous souhaitez voir des copies d’écran de l’interface web d’administration, vous pouvez consulter la documentation.

MySolrServer est actuellement en mode bêta avec quelques conditions d’utilisation temporaires durant cette période.

La première chose a vérifier avent de se lancer dans l'installation de Vmware vSphere Hypervisor, c'est la compatibilité matérielle de votre serveur. Par exemple, les 2 cartes réseaux de la carte mère ASUS P6T Deluxe V2 ne sont pas compatibles. J'ai du les désactiver et utiliser à la place une carte réseau Intel PRO 1000 GT PCI. 

Les étapes de la migration sont:

• télécharger vSphere Hypervisor sur le site Vmware et récupérer une clé de licence gratuite
• récupération de toutes les vm hébergées sur le serveur OpenSuse sur un disque de backup. Ce disque doit être accessible depuis un poste Windows XP ou Seven car les images qui s'y trouvent serviront pour leur réinstallation sur le serveur vSphere Hypervisor.
• installation de vSphere Hypervisor. Suivre ce guide sur le site Tuto-IT. Apres l'étape impérative du choix d'un mot de passe (le client vSphere ne peut pas se connecter au serveur sans mot de passe), il faut absolument en profiter pour autoriser les accès SSH à ESXi. Pour cela, aller dans le menu "Troubleshooting options".
• installation du client vSphere sur un poste Windows
• installation Vmware vCenter Converter Standalone sur un poste Windows
• importation des machine virtuelles

Problèmes rencontrés lors de l'importation de mes machines virtuelles

Dans le récapitulatif pré-conversion, bien vérifier que le disque dure est de type "Léger" et non pas "Plat". En mode "Plat", la totalité de l'espace disque est pré-alloué dans le datastore.

Vmware vCenter Converter ne reconnait pas automatiquement les distributions Debian. J'ai du manuellement modifier le type de distribution en indiquant Debian 5.0 64 bits (pour Lenny et Squeeze). Plus tard, dans le client vSphere, la mise à jour automatique des Vmware tools se passera sans aucun soucis dans le mode automatique.

Je n'ai pas réussi à importer 2 clients Windows XP Pro qui étaient dans Vmware Server 2.0. J'ai du utiliser une machine virtuelle Windows XP qui tourne sous Vmware Fusion. J'y ai remplacé le fichier vmdk par ceux des VM que je ne réussissais pas à importer. 

Les backups

Dans vSphere Hypervisor, il n'y a pas de solution de backup intégrée. Je vous conseille les scripts ghettoVCB disponibles sur le site de Vmware (du sérieux donc) :

• sauvegarde
• restauration

Templates

Il n'y a pas non plus de solution de VM Template que l'on peut cloner pour mettre en place rapidement un nouveau serveur.

Pour contourner ce problème, j'ai importé ma VM Debian 6.0 de base et je l'ai nommée "_TEMPLATE_DEBIAN_60_64B". Cette VM n'a pas vocation à être allumée sauf une fois pour la mettre à jour ("aptitude update" et "aptitude upgrade") et mettre à jour les Vmvare tools.  

Pour déployer un nouveau serveur, je me connecte en ssh à ESXi, je copie le répertoire de la VM template sous un autre nom dans le même datastore ou dans un autre. Puis, j'enregistre la nouvelle VM dans ESXi avec la commande suivante :

/bin/vim-cmd solo/registervm <chemin_complet_du_fichier_vmx_de_la_vm_a_activer>

Pour cet article, je pars d’une image debian-6.0.0-amd64-netinst.iso. Je déroule la procédure d’installation simplement afin d’arriver à un serveur de base vierge d’interface graphique et de tous logiciels sauf SSH. Je vais décrire maintenant les étapes de l’installation des packages complémentaires afin de disposer de Apache, MySQL, PHP, Java et Tomcat. Ceci peut vous intéresser, mais c’est également un aide mémoire pour moi-même. C’est un peu technique, mais je n’entre pas dans les détails.

Dans le précédent article j’utilisais le gestionnaire de package Apt. Je profite de cette mise à jour pour utiliser Aptitude. Afin que la gestion ds dépendance, les mises à jours et les suppressions fonctionnent correctement, il faut éviter d’utiliser alternativement les 2 outils sur un même serveur. Il faut donc faire attention à ne plus utiliser par réflexe apt-get et apt-cache.

Les commandes qui sont indiquées doivent être exécutées sous le compte root ou avec sudo (on va voir sudo plus loin).

Mettre à jour les dépots Apt / Aptitude

Apt et Aptitude, sont les outils qui permettent d’installer des packages et de gérer les dépendances. Les 2 outils utilisent les mêmes dépots. La mise à jour en question a pour but de mettre à jour la liste des packages disponibles.

Je commence par modifier le fichier /etc/apt/sources.list pour ajouter les dépots contrib et non-free ainsi que pour désactiver le CDROM. Mon fichier contient ceci :

#
 
# deb cdrom:[Debian GNU/Linux 6.0.0 _Squeeze_ - Official amd64 NETINST Binary-1 20110205-14:31]/ squeeze main
 
#deb cdrom:[Debian GNU/Linux 6.0.0 _Squeeze_ - Official amd64 NETINST Binary-1 20110205-14:31]/ squeeze main
 
deb http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ squeeze main contrib non-free
 
deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free
 
deb http://ftp.fr.debian.org/debian/ squeeze-updates main contrib non-free
deb-src http://ftp.fr.debian.org/debian/ squeeze-updates main contrib non-free

Et enfin :

aptitude update

Installation du serveur OpenSSH

Dans mon installation de base, j’ai installé le serveur SSH sur le serveur. Si ce n’est pas fait, il faut installer OpenSSH depuis la console physique de serveur.

aptitude install openssh-server

Création de l’utilisateur « dominique »

useradd -d /home/dominique -m -s /bin/bash dominique      

passwd

Installer sudo

sudo permet d’exécuter des commandes comme utilisateur root sans être connecté sous le compte root.

aptitude install sudo

Déclarer l’utilisateur dominique dans sudo en ajoutant la ligne suivante dans « /etc/sudoers »

dominique ALL=(ALL) ALL

A partir de là, tout se fait si possible sous le compte « dominique » (et utilisation de sudo pour les actions nécessitants les droits root).

Augmentation des limites systèmes (optionnel)

Pour mes besoins j’ai besoin d’augmenter certaines limites systèmes. Cela se fait en éditant le fichier  /etc/security/limits.conf

vi /etc/security/limits.conf

Personnellement, j’y ajoute les lignes suivantes :

*                soft    nofile        8192
*                hard    nofile        16384
*                soft    stack         16384
*                hard    stack         32768

Installation de apache2.2

sudo aptitude install apache2

Activer le mode rewrite

sudo a2enmod rewrite

sudo /etc/init.d/apache2 restart

Installation de mysql server 5.1

sudo aptitude install mysql-server-5.1

Installation PHP 5

J’ai besoin de PHP 5 et quelques librairies complémentaires (curl par exemple pour appeler des web services en http, mysql, PEAR, …).

sudo aptitude install php5 php5-cli libapache2-mod-php5 php5-curl php5-gd php5-mysql php5-dev
sudo aptitude install locales-all

Installation et mise à jour de PHP PEAR

sudo aptitude install php-pear

sudo pear upgrade PEAR

Puis installation de quelques modules Pear

sudo pear install Mail Net_Smtp

Modification du php.ini

Editer « /etc/php5/apache2.php.ini » et mettre

output_buffering=4096

Installation d’un JDK

On peut soit installer openJDK 6 ou Sun JDK 6

openJDK

sudo aptitude install openjdk-6-jre openjdk-6-jdk

Sun JDK

sudo aptitude install sun-java6-jdk sun-java6-fonts

Installation de tomcat 6

sudo aptitude install tomcat6 tomcat6-admin

Installation de pdftotext

sudo aptitude install xpdf-utils

Installation de lftp

lftp est un client ftp qui sera utile pour mettre les sauvegardes sur le serveur FTP mis a disposition par OVH.

sudo aptitude install lftp

Paramétrage de apache

Copier le fichier de configuration de mon virtualhost dans « /etc/apache2/site-available« ,
activer le site et relancer Apache.

sudo a2ensite xxxxxx (ou xxxxxx est le nom du fichier .conf du virtualhost)
sudo /etc/init.d/apache2 reload

Paramétrage Tomcat

Dans /var/lib/tomcat6/conf/server.xml, on vérifie que le connecteur non-SSL inclut l’attribut « URIEncoding= »UTF-8″ ». C’est le cas apparemment par défaut maintenant.

    <!-- Define a non-SSL HTTP/1.1 Connector on port 8080 -->
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               URIEncoding="UTF-8"
               redirectPort="8443"/>

Sous Debian, Tomcat est très sécurisé. Une autre manière radicale de passer outre cette sécurisation est de la désactiver dans le fichier « /etc/init.d/tomcat6″, en indiquant :

TOMCAT6_SECURITY=no

Je constate que c’est la configuration par défaut maintenant. Par contre, je ne me permet ceci parce que je n’autorise l’accès à mon serveur Tomcat que localement. Dans /var/lib/tomcat6/conf/server.xml, j’ajoute une définition de valve au niveau engine :

    <Engine name="Catalina" defaultHost="localhost">
      <Valve className="org.apache.catalina.valves.RemoteAddrValve"
         allow="127.0.0.1" deny=""/>

Je change également le fichier « /etc/default/tomcat6″ pour lui indiquer le bon timezone et augmenter ses ressources mémoires. Editer le fichier « /etc/default/tomcat6″, pour modifier la ligne JAVA_OPTS=…

JAVA_OPTS="-Djava.awt.headless=true -Xms256M -Xmx1024M -Duser.timezone=Europe/Paris -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC"

Relancer tomcat

sudo /etc/init.d/tomcat6 restart

Installer le compilateur GCC et l’outil make

sudo aptitude install gcc g++ make

Installer memcached

sudo aptitude install memcached php5-memcache

Dans cet article,  je décris memcached.

Pour son installation à partir des sources, suivre la procédure parfaitement décrite dans cet article. Par contre, il faut vérifier quelles sont les dernières versions des modules à télécharger.

Installer ntpdate

sudo aptitude install ntpdate

Pour mettre à l’heure en utilisant le serveur de temps de l’observatoire de Paris

sudo /usr/sbin/ntpdate ntp-p1.obspm.fr

Dans la crontab ajouter la ligne suivante afin de synchroniser l’heure tous les matins à 3h

0 3 * * * root /usr/sbin/ntpdate ntp-p1.obspm.fr >/dev/null

Installer fail2ban

En fonctionnement, un serveur s’expose à des attaques. Fail2ban permet de se protéger contre les attaques de masse sur certains ports TCP ou UDP en attente de connexion. Le premier protocole à protéger (le seul exposé à la livraison du serveur lorsque qu’il n’y a pas de logiciel complémentaire installé) est ssh. Ssh permet de prendre la main sur un serveur à distance. Mais si on connaît le port d’attente (22 par défaut) et le mot de passe root, on peut tout faire sur le serveur. Fail2ban scrute les logs des services en attente de connexion pour déterminer si une attaque est en cours et si donc il doit bloquer l’adresse IP de l’attaquant.

sudo aptitude install fail2ban

dans « /etc/fail2ban/jail.conf », j’ajout mon ip perso dans les ip a ignorer

ignoreip = 127.0.0.1 82.xxx.xxx.xxx

redémarrage de fail2ban

sudo /etc/init.d/fail2ban restart

Concernant la sécurité, on peut  (et on doit) aller plus loin, mais cela n’ai pas couvert par cet article.

Cas de l’installation sous Vmware server 2.0

Dans ce cas, il faut installer les vmware tools. Pour cela :

1. Dans l’administration Web Vmware Server 2.0, cliquer sur « Install VMware Tools » du serveur en question

2. Ouvrir une console Vmware pour accéder au serveur, se connecter sous le compte root et exécuter les commandes suivantes :

aptitude install autoconf automake binutils cpp gcc linux-headers-$(uname -r) make psmisc
mount /media/cdrom
cp /media/cdrom/VMwareTools-7.7.6-203138.tar.gz /tmp/.
cd /tmp/
tar xvfz VMwareTools-7.7.6-203138.tar.gz
cd vmware-tools-distrib/
./vmware-install.pl

Voici quelques commandes simples et bien utiles utilisant curl afin de manipuler un index Solr.

• Supprimer un document à partir de sa valeur de clé unique
• Supprimer un document à partir d'une requête
• Vider totalement un index
• Forcer un commit d'un index
• Forcer un optimize d'un index

Supprimer un document à partir de sa valeur de clé unique :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<delete><id>SP2514N</id></delete>"

Supprimer un document à partir d'une requête :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<delete><query>type:book</query></delete>"

Vider totalement un index :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<delete><query>*:*</query></delete>"

Forcer un commit d'un index :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<commit/>"

Forcer un optimize d'un index :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<optimize/>"

Pour plus d'exemples, vous pouvez consulter cette page du Wiki Solr : http://wiki.apache.org/solr/UpdateXmlMessages

Voici la méthode pour intégrer le patch suivant : https://issues.apache.org/jira/browse/SOLR-785

• Commencer par récupérer une distribution des sources de Solr (http://www.apache.org/dyn/closer.cgi/lucene/solr/).
• Décompresser l'archive dans un répertoire. Pour l'exemple on utilise /tmp, ce qui donne un répertoire /tmp/apache-solr-1.4.1
• Dans /tmp/apache-solr-1.4.1, placer le fichier correspondant au patch (pour le patch SOLR-785, c'est SOLR-785.patch)
• Patcher
  cd /tmp/apache-solr-1.4.1
patch -p0 -i SOLR-785.patch
• Recompiler
  ant clean
ant dist

Le war compilé est dans le répertoire dist

Depuis quelques semaines je collabore à un projet qui nécessite un travail en équipe et qui impose donc un outil de gestion de sources. N’ayant pas le choix, j’ai bien du m’y mettre et avec l’assistance de mes partenaires de travail, ça c’est finalement passé vite et plutôt facilement. Cet outil, c’est Mercurial (également appelé Hg).

Je ne vais pas vous faire ici une étude comparée de Subversion et de Mercurial car ceci est déjà très bien fait sur le blog PilotSystems. Je dirai juste que contrairement à Subversion qui utilise un dépôt unique centralisé par tous les développeurs, Mercurial utilise 2 types de dépôt : un dépôt local et un dépôt central. L’avantage de ce système dans mon cas est que pour la plupart de mes projets, le dépôt local me suffit car je travail seul. Le dépôt local permet toutes les opérations dont on a besoin au minimum : commit, update revert, diff, tags, branch, …

Un autre point à l’avantage de Mercurial est que le dépot local est constitué d’une arborescence de fichiers simples à sauvegarder et que les sources ne sont pas pollués par des fichiers cachés dans chaque répertoires des sources.

Je n’utilise par Mercurial depuis Eclipse mais soit en ligne de commandes (il n’y a pas tant de commandes que ça) soit avec l’interface graphique MacHG.

Tutoriaux et arcticles

Voici les bons tutoriaux que j’ai trouvé (par ordre de préférence) :

• HGInit : a Mercurial tutorial
• Un tutorial en français sur l’utilisation de Mercurial
• Mercurial : the definitive guide
  

Une très bonne série d’articles par Steve Losh sur l’utilisation des branches :

• A Guide to Branching in Mercurial
• Mercurial Workflows: Branch As Needed
• Mercurial Workflows: Stable & Default
• Mercurial Workflows: Translation Branches
  

Outils de Merge et de Diff

Tout d’abord, configurer l’outil de comparaison (diff) et d’assistance au merge. En ligne de commande, par défaut, il n’y a pas d’outil de diff et de merge actif et avec MacHg par défaut, c’est Filemerge qui est utilisé si XCode est installé. Le problème avec Filemerge, c’est qu’il ne réussi pas toujours à afficher les différences et qu’il ne peut pas comparer simultanément 3 versions d’un même fichier pour gérer efficacement les merges.

J’ai donc choisi d’installer Diffmerge. La procédure d’installation est bien documentée et simple (dans le fichier Readme). Il faut bien aller jusqu’au bout en installant les scripts de lancement en ligne de commande. Pour l’intégration à Mercurial, cela se passe dans le fichier ~/.hgrc et c’est également bien documenté sur le wiki de Mercurial. Pour une utilisation avec MacHg, il faut aller sur l’onglet « Advanced » des préférences de MacHg. Positionner les options de la zone « Merge and Diff Tool » comme indiqué dans la copie d’écran ci-dessous.

Gestion des mots de passe par dépot

Lors d’un accès aux dépôts centralisés, il est demandé un login. Il est possible de stocker ces login par dépôt dans le fichier ~/.hgrc. Tout se passe dans la section « [auth] » comme indiqué dans cet exemple.

[auth]
bb1.prefix = https://sources.depot1.org/
bb1.username = dominique
bb1.password = xxxx

bb2.prefix = https://sources.depot2.net/
bb2.username = dom
bb2.password = yyyy

...

bbN.prefix = https://sources.depotNN.fr/
bbN.username = domi
bbN.password = zzzz

Mise à jour du 19 septembre 2011 :

Depuis l’écriture de cet article, j’ai également travaillé avec Git un autre outils de gestion de source. Tout comme Mercurial, Git est une solution comportant un  dépôt local et et un dépôt central. Bien que le principe soit le même, les commandes varient sensiblement et je trouve finalement Git plus complexe à utiliser que Mercurial. Je suis entre autre perturbé par l’absence de commandes simples similaire à hg incoming et hg outgoing.

Après plusieurs mises en production chez des clients et les différents retours d'expériences, un certain nombre de nouvelles fonctionnalités ont été ajoutées à Crawl Anywhere. Une liste des principales nouvelles fonctionnalités est disponible sur le wiki dans la release note.

Un bon rappel des concepts de base.

[slideshare id=5658889&doc=zendconsolrphp-101103144414-phpapp02]