Posts tagged with svn

Pourquoi l'utilisation de GIT surpasse-t'elle celle de SVN pour des développeurs

Nov 17, 2008 in git, programmation, svn | Informatique

Cela fait presque 2 mois que j’utilise git et git-svn au lieu de svn, pour Wormux ou dans mon travail. Git est sans doute plus complexe que subversion, mais cette complexité apporte quelques avantages (je suis plutôt réservé quant aux avantages pour des graphistes ou autres).

Le micro-commit

Avec git, plus d’hésitation à “commiter” localement les fichiers une fois qu’on commence à avoir quelque chose de convenable. Si au final, ce n’était pas une bonne idée, il suffira de revenir en arrière dans l’historique mais les autres développeurs ne seront pas impactés. Ça permet d’avoir des messages de commits plus précis, et des modifications plus fines par commit, plus facile à annuler et à comprendre. On est alors dans un cycle de développement beaucoup plus itératif.

Admettons qu’on veuille faire une modification massive de l’organisation du code et qu’on souhaite que tout ne soit visible qu’en version “finale” aux autres développeurs, car on est pas sûr à 100% de ce qu’on va faire, et que l’on craigne devoir revenir en arrière plusieurs reprises dans le processus. Avec git, à chaque étape, on fait un commit, et si finalement les dernières modifications (non commitées) ne conviennent pas, on utilisera git stash ou git checkout HEAD pour annuler ces modifications. Une fois qu’on est satisfait, on envoie le tout sur le dépôt centralisé avec git svn dcommit :)

Avec subversion, il est probable qu’on n’ait pas osé commiter chaque petite modification, et du coup, dès qu’il faut revenir en arrière, c’est galère :(

La gestion de branche locale à porter de main

L’autre avantage, c’est la facilité avec laquelle on peut gérer des branches locales. Par défaut, avec git-svn, on a une branche locale appelée master. Personnellement, je ne fais aucune modification sur cette branche et me contente de la maintenir à jour par rapport au trunk svn à l’aide des commandes suivantes :

  • git svn fetch pour mettre à jour l’historique par rapport aux modifications apportées sur le dépôt centralisé SVN. Ça n’applique pas ces modifications sur votre copie locale.
  • git checkout master pour passer sur la branche master. Nécessaire uniquement si vous étiez sur une autre branche.
  • git rebase trunk pour synchroniser la branche courante avec la branche distante trunk.

Je fais toutes mes modifications sur une autre branche, appelons là local-devel. Je crée la branche avec git branch local-devel puis passe sur cette branche avec git checkout local-devel. À partir de là, je commence à travailler puis commite localement de temps en temps.

Il m’est arrivé par 2 fois d’avoir une correction de bug plus urgente à faire. Je repasse alors sur la branche master (git checkout master), je la met à jour (git svn fetch && git rebase trunk), je branche (git branch fastfix && git checkout fastfix), je corrige le bug, je compile, je teste, je commite localement (git commit -a), je propage la modification (git svn dcommit), je remet à jour ma branche master (git checkout master && git rebase trunk) et efface la branche devenue inutile (git branch -D fastfix) puis je retourne ensuite à mon développement standard que je rebase sur la branche master (git checkout local-devel && git rebase master). C’est une certaine gymnastique, mais au final, c’est plus confortable que faire un svn diff qu’on redirige dans un fichier pour ré-appliquer le patch plus tard ;)

De SVN à Git, découverte concrète autour du projet Wormux - Vers l'utilisation basique

Sep 25, 2008 in git, programmation, svn | Informatique

Maintenant que le projet a été importé, il est possible de travailler normalement en éditant ses fichiers avec son éditeur de texte favori.

De la même manière qu’avec SVN, on peut renommer des fichiers avec Git en utilisant git mv nom_de_fichier_actuel futur_nom_de_fichier.

Avant de propager les modifications dans l’historique local, on va d’abord vérifier les changements, avec git diff [mes_fichiers]. Contrairement à svn diff, il est suffisamment intelligent pour ouvrir directement dans le pager. git diff [mes_fichiers] est donc plus ou moins équivaleut à svn diff [mes_fichiers] | less.

Pour voir uniquement le noms des fichiers modifiés sans voir les modifications, on fera git diff --name-only [sous-répertoire].

Git étant décentralisé, on va d’abord propager localement les modifications avec git commit. Contrairement à SVN, avec Git, par défaut, git commit n’agit sur aucun fichier. On peut faire git commit -a pour commiter (bouh, le vilain franglais!) tous les fichiers (déjà surveillés) modifiés. Ou alors, avant d’appeler git commit on peut appeler git add mes_fichiers que mes_fichiers soient déjà présents ou non dans le dépôt. git commit prendra alors en compte tous le fichiers sur lequel on a fait un git add. Dernière possibilité, git commit mes_fichiers. Bien évidemment, git commit demande ensuite de remplir un commentaire sur la modification effectuée et refuse si le commentaire est vide :)

Viens ensuite le moment de la propagation dans le dépôt central SVN, avec git-svn dcommit. On pourrait se dire que ça oblige à taper 2 commandes au lieu d’une (git commit mes_fichiers, git-svn dcommit au lieu de svn commit) mais ça permet de faire des plus petits commits qu’on ne propagera globalement qu’une fois un peu plus de travail effectué. Au final, en profitant bien de cette possibilité, ça permet d’avoir un historique de meilleur qualité :)

De SVN à Git, découverte concrète autour du projet Wormux - téléchargement de l'historique du dépôt SVN

Sep 15, 2008 in git, svn, wormux | Informatique

Actuellement co-développeur du jeu libre Wormux, la gestion de version est une problématique importante lors de la sortie d’une nouvelle version. Git semble être une révélation pour de nombreux développeurs et montre son efficacité sur le noyau Linux.

Itinéraire d’une migration progressive de SVN à Git, par l’utilisation de git-svn… Commençons par créer le répertoire qui va héberger notre dépôt git local :

$ mkdir git-svn
$ cd git-svn

Puis initialisons le dépôt :

$ git-svn init --trunk=trunk --tags=tags --branches=branches svn+ssh://gentildemon@svn.gna.org/svn/wormux
Initialized empty Git repository in .git/

C’est parti pour le téléchargement de l’historique du dépôt Subversion, quelques dizaines de minutes d’attente en perspective :

$ git-svn fetch

À la fin, vous devriez voir quelque chose comme :

Checking out files: 100% (2018/2018), done.
Checked out HEAD:
  svn+ssh://gentildemon@svn.gna.org/svn/wormux/trunk r5099

Si il y a eu de nouveaux commits, il faut relancer git-svn fetch pour les obtenir.

Vous pouvez voir les branches présentes sur le dépôt svn avec la commande suivante :

$ git branch -r
 0.8-final
 0.8beta4
 tags/wormux-0.7
 tags/wormux-0.7.2
 tags/wormux-0.7.3
 tags/wormux-0.7.4
 tags/wormux-0.7.9
 tags/wormux-0.7.9rc1
 tags/wormux-0.7beta3
 tags/wormux-0.8
 tags/wormux-0.8alpha1
 tags/wormux-0.8beta1
 tags/wormux-0.8beta2
 tags/wormux-0.8beta3
 tags/wormux-0.8beta4
 trunk
 wormux-0.7
 wormux-0.7.9
 wormux-0.8.1
 wormux-0.8beta1
 wormux-0.8beta2

Par défaut, on ne voit que le contenu du trunk svn.

La suite, ce sera pour un autre jour, afin d’éviter de faire trop de bêtises ;)

SVN - Suivi de branche avec svnmerge (Mini Howto-FR)

Aug 31, 2007 in svn | Informatique

svnmerge != svn merge

svn merge est une commande intégrée à SVN

svnmerge est un petit outil pratique (script python) pour faciliter la gestion de branches avec SVN.

Que fait svnmerge :

  • garde la trace des révisions déjà fusionnées
  • permet de choisir les révisions à fusionner
  • permet de bloquer des révisions (pour ne jamais les fusionner)
  • autorise le retour arrière sur révision
  • crée des messages clairs pour les commits