Euh tu va un peu vite en besogne pour SVN. Je ne serais pas celui qui le défend bec et ongle, mais il permet des choses que git et mercurial ne permettent pas. Voir pour un retour d'expérience: http://live.gnome.org/GitMigration
Par exemple un sparse checkout: les traducteurs ouzbeks de logiciels GNOME doivent maintenant télécharger tous le logiciel au lieu de simplement faire un checkout sur le répertoire des traductions avec un debit internet famélique. Pareil pour ceux qui ne travaillent que sur le répertoire site/ pourquoi devraient ils prendre le code source aussi?
Lors d'un merge, si les heuristiques de Git ne marchent pas dans ton cas, alors pas de bol pour toi. Par exemple: nous avons réorganisé le code pour le rendre plus modulaire (déplacement de repertoires , de fichiers, etc.). Quand j'ai essaye Git pour faire un merge de fichiers ajoute a un ancien répertoire, Git me l'a recrée dans un répertoire qui n'existe plus dans la branche ou je fais le merge! Mercurial doit mieux gérer ce cas la je pense puisqu'il gère individuellement les fichiers. Par contre cette faculté de Git lui permet de se rappeler toutes les lignes de codes, même si le code a été déplacé dans un autre fichier.
Enfin, le plus gros argument, c'est que pour une grosse équipe de développement, passer de SVN a Git/Mercurial implique un grand changement dans la façon de travailler, parce que l'outil ne fait pas tout et que les humains sont plus essentiels que les outils. Si les gens sont plus a l'aise avec SVN parce que SVN est beaucoup plus simple a comprendre, alors peut être que les outils plus avancés ont manqué quelque chose? Un exemple a la con serait Google Wave qui devait rendre l'email, l'IM, les wikis et les forums obsolètes, pourtant toutes ces choses sont encore la et pas encore dépassées (J'avais prévenu que c'était un exemple a la con).
Bien sur je ne dénie pas les avantages qu'apporte Git et Mercurial, mais tout n'est pas rose non plus et SVN est encore la pour un bon bout de temps. Donc SVN n'est pas si dépassé ni même prêt de disparaître.
[^] # Re: Sauvegarde locale
Posté par djano . En réponse à la dépêche Sortie de GNU CSSC 1.3.0. Évalué à 3.
http://live.gnome.org/GitMigration
Par exemple un sparse checkout: les traducteurs ouzbeks de logiciels GNOME doivent maintenant télécharger tous le logiciel au lieu de simplement faire un checkout sur le répertoire des traductions avec un debit internet famélique. Pareil pour ceux qui ne travaillent que sur le répertoire site/ pourquoi devraient ils prendre le code source aussi?
Lors d'un merge, si les heuristiques de Git ne marchent pas dans ton cas, alors pas de bol pour toi. Par exemple: nous avons réorganisé le code pour le rendre plus modulaire (déplacement de repertoires , de fichiers, etc.). Quand j'ai essaye Git pour faire un merge de fichiers ajoute a un ancien répertoire, Git me l'a recrée dans un répertoire qui n'existe plus dans la branche ou je fais le merge! Mercurial doit mieux gérer ce cas la je pense puisqu'il gère individuellement les fichiers. Par contre cette faculté de Git lui permet de se rappeler toutes les lignes de codes, même si le code a été déplacé dans un autre fichier.
Enfin, le plus gros argument, c'est que pour une grosse équipe de développement, passer de SVN a Git/Mercurial implique un grand changement dans la façon de travailler, parce que l'outil ne fait pas tout et que les humains sont plus essentiels que les outils. Si les gens sont plus a l'aise avec SVN parce que SVN est beaucoup plus simple a comprendre, alors peut être que les outils plus avancés ont manqué quelque chose? Un exemple a la con serait Google Wave qui devait rendre l'email, l'IM, les wikis et les forums obsolètes, pourtant toutes ces choses sont encore la et pas encore dépassées (J'avais prévenu que c'était un exemple a la con).
Bien sur je ne dénie pas les avantages qu'apporte Git et Mercurial, mais tout n'est pas rose non plus et SVN est encore la pour un bon bout de temps. Donc SVN n'est pas si dépassé ni même prêt de disparaître.