Je ne m'en cache pas, je suis un pro git à fond. Cependant et malheureusement, git n'est pas (encore) très répandu et beaucoup de projets sont encore hébergés sur des repositories SVN. C'est le cas chez O2Sources (mais on parle d'y remédier, notamment lorsque Townce gèrera cela).
Vu que je viens de migrer ma machine de Windows vers Ubuntu, j'ai décidé d'en profiter pour faire un test. Utiliser git-svn pour commiter en local en git et pousser par la suite sur le repository svn :)
Déjà, l'installation. Sous Debian-Like,
sudo aptitude install git-svn
Normalement, cela vous crée une commande "git-svn". Moi, ça l'a pas fait. Du coup un petit coup de sudo find / -name git-svn; vous trouvez l'emplacement de l'exécutable (théoriquement dans /usr/bin) et y créer une commande globale.
ln -s /chemin/vers/git-svn /usr/bin/git-svn
Ensuite, commençons par récupérer notre repository
git-svn clone -s http://domaine.net/chemin/vers/le/repository
Si vous avez une arborescence avec des tags (dossiers tags/, trunk/ et branchs/), placez l'option -s.
Ainsi, git-svn les convertira en tags et branches GIT.
Sinon, c'est inutile :)
Deuxième étape : si vous avez des options git:ignore, elles ne sont pas prises en compte. Faites les donc :
git-svn show-ignore > .gitignore
Maintenant, faites vous une session de développement. Committez comme d'habitude sur votre repository git et oubliez svn (youpi !!). Une fois que celle-ci est terminée, il vous faut committer (bah ouais hein).
Pour cela, commencons par faire un update. On sait jamais que vous seriez pas le seul à travailler et que l'un de vos collègues n'ait committé entre temps ;)
git-svn rebase
Et committons
git-svn dcommit
Vous verrez que votre repository svn a été mis à jour. Cool non ? :) Et vous, vous préférez GIT ou SVN ? (ouais, postez des commentaires !!)
Commentaires
Pour l’instant je n’ai utilisé git que pour récupérer les sources de deux ou trois projets, donc je ne saurais me prononcer.
Par contre, je voulais savoir si tu avais déjà testé voire pratiqué Mercurial, le principal concurrent de git dans les systèmes de contrôle de version next-gen (il me semble que bazaar est un peu en retrait)? Il me semble que la communauté Django est très Mercurial.
Non, je n'ai jamais testé et encore moins pratiqué mercurial. Je suis plus proche de la communauté Rails que Django et ces premiers sont très git :)
Par ailleurs, j'ai l'impression que git est plus développé que mercurial. Mais c'est peut-être une impression biaisée par mon attachement à la communauté ruby/rails.
Pour avoir pratiqué un peu des deux (mercurial et git), je les trouve très similaire dans leur approche mais je reste néanmoins un utilisateur de svn qui compte migrer totalement vers l'un ou l'autre d'ici peu de temps.
Je pense pas que git est plus développé que mercurial, mais celui-ci est, de mon point de vue, beaucoup plus populaire notamment grâce à son créateur et à github qui a un peu plus d'aura qu'un bitbucket.
Cependant, le fait que CPython migre sur mercurial risque pas mal de changer la donne : http://mail.python.org/pipermail/python-dev/2009-July/090325.html
Très sympa git-svn, je bookmark ;)
Ah tiens, je constate aussi que Google Code propose maintenant Mercurial en plus de SVN (seul choix jusqu'ici).
La plupart des comparatifs Mercurial/Git que je lis datent de 2008, et soulignent pour les défauts de Git une certaine complexité des commandes (par opposition à Mercurial qui s'inspirerait en partie de SVN pour les noms de commande, facilitant ainsi la transition de l'un à l'autre), et l'absence de client Windows officiel (voire officieux). Il me semble que sur ce dernier point la situation s'est améliorée depuis un an, mais la disponibilité de TortoiseHg pour Windows et Gnome est un argument de poids pour la Source.
NB : en ce qui concerne le lien vers git-svn ce n'est pas nécessaire : la commande est normalement git svn (avec un espace)
Le lien n'était pas bon effectivement. C'est la documentation de git qui mentionne "git-svn" pour "git svn".
git-svn est vraiment sympa. Mais c'est vrai que les messages de git sont souvent obscurs:
Cannot dcommit with a dirty index. Commit your changes first, or stash them with `git stash'.
Me laisse perplexe...
Un "dirty index" signifie que tu a des fichiers modifiés et non commités dans ton repository. Il faut les committer avant de pouvoir pousser sur le repository.
Après deux petits mois d'accoutumance, en effet, git est très très bien.
Par contre, quand vous débutez avec git svn, gardez un petit truc en tête: quand vous faîtes un git svn dcommit, et que vous commitez vos dix derniers commits, par exemple... et bien dans git lui-même, vos commits sont modifiés! C'est donc une opération un peu délicate de suivre une branche dans un dépôt qui utilise git svn. En effet, il suffit d'un git fetch pour avoir divergé de 10 commits...
Heureusement, avec gitk --all et git rebase, on finit toujours par s'en sortir, mais c'est pénible...
Ah oui! et
git svn clone svn+ssh://user@adresse/depotsvn -T trunk -b branches -t tags
est très utile: vous récupérer toutes les branches et tous les tags automatiquement.
Au lieu de ln -s /chemin/vers/git-svn /usr/bin/git-svn, fait simplement 'git svn' à la place de 'git-svn' (git svn appellera /usr/lib/git-core/git-svn))