Lionel DebrouxLe 05/12/2012 à 22:12
Depuis 2007, après un court passage par SVK (surcouche à SVN pour permettre un peu d'utilisation en tant que SCM distribué), j'utilise quasi-exclusivement Git, au boulot comme en temps libre, en général au-dessus de SVN.
Git a "toujours" eu un excellent support de SVN, ce qui n'était pas le cas de Mercurial pendant longtemps.
Git et Mercurial sont plus difficiles à prendre en main que SVN, mais bien entendu, beaucoup plus puissants
Pour Git et Mercurial: le miroir local de tout l'historique des commits est pratique pour le travail en mode déconnecté / quand le serveur distant foire. Et pas de souci à se faire pour le stockage de milliers de révisions, Git et Mercurial utilisent une représentation très efficace des données. Du style, ~10K révisions d'un arbre SVN qui représente ~140K fichiers dans ~60K répertoires, pour ~400 MB dans le répertoire .git de la racine (et encore, il y a eu quelques fichiers binaires de quelques MB committés par erreur);
Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.
Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.
Quand on utilise Git au-dessus de SVN, il est rare d'avoir à repasser à SVN pour faire des manipulations. Une des principales raisons de ce faire que j'ai rencontrées est la suppression des répertoires vides suite à un renommage, Git ne versionnant pas les répertoires vides. En revanche, je n'ai pas subi de pertes d'historique, ni vu beaucoup de plaintes à ce sujet
gitk est un excellent visualiseur d'historique, et git gui permet de faire un certain nombre d'opérations pour committer, pousser, etc.; j'utilise aussi largement l'interface en ligne de commande (de toute façon, même si je voulais, difficile de faire autrement sur les machines headless sans serveur X ^^).
Git a "toujours" eu un excellent support de SVN, ce qui n'était pas le cas de Mercurial pendant longtemps.
Git et Mercurial sont plus difficiles à prendre en main que SVN, mais bien entendu, beaucoup plus puissants
Pour Git et Mercurial: le miroir local de tout l'historique des commits est pratique pour le travail en mode déconnecté / quand le serveur distant foire. Et pas de souci à se faire pour le stockage de milliers de révisions, Git et Mercurial utilisent une représentation très efficace des données. Du style, ~10K révisions d'un arbre SVN qui représente ~140K fichiers dans ~60K répertoires, pour ~400 MB dans le répertoire .git de la racine (et encore, il y a eu quelques fichiers binaires de quelques MB committés par erreur);
Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.
Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.
Quand on utilise Git au-dessus de SVN, il est rare d'avoir à repasser à SVN pour faire des manipulations. Une des principales raisons de ce faire que j'ai rencontrées est la suppression des répertoires vides suite à un renommage, Git ne versionnant pas les répertoires vides. En revanche, je n'ai pas subi de pertes d'historique, ni vu beaucoup de plaintes à ce sujet
gitk est un excellent visualiseur d'historique, et git gui permet de faire un certain nombre d'opérations pour committer, pousser, etc.; j'utilise aussi largement l'interface en ligne de commande (de toute façon, même si je voulais, difficile de faire autrement sur les machines headless sans serveur X ^^).