Attention: Depuis ce billet, j'ai trouvé Mercurial et je l'aime beaucoup mieux que SVN. Donc, ce post est un peu obsolète avec les commentaires Pro SVN et anti-DVCS en général, mais le contenu anti-git est toujours d'actualité
Je suis fan de SVN sur Git.
Pourquoi? Parce que SVN était beaucoup plus facile pour un seul développeur ou une petite équipe, et que git (en particulier msysgit) me laissait un mauvais goût dans la bouche.
Lorsque je faisais mon stage dans un petit magasin, on m'a initié à git sous Windows. J'ai immédiatement remarqué la quantité de travail nécessaire pour que cela fonctionne avec Github. Tout d'abord, je devais générer une clé privée ssh, coller la clé publique dans Github, puis faire apparaître une reconstitution historique et ouvrir ma clé privée chaque fois que je voulais pousser, ce qui était extrêmement ennuyeux.
Et je n’ai jamais vraiment aimé que j’arrache tout le référentiel. J'admettrai que je n'ai jamais travaillé avec quoi que ce soit d'énorme, mais j'aurais peur de télécharger le référentiel de KDE dans Git si l'ensemble du référentiel et ses révisions sont sur mon disque dur.
Ensuite, il y avait le processus déroutant pour faire un commit. TMK, je devais d'abord "mettre en scène" tous les fichiers que je voulais valider (ce qui était dommage lorsque vous aviez beaucoup de fichiers, il m'a fallu un certain temps pour trouver la commande manuelle pour tout mettre en scène), puis faites le commit, puis appuyez sur la touche principale. repo (pourquoi est-ce une opération séparée?!).
Vous avez également eu les données de validation pas (!) Très utiles. Oh regardez, c’est une partie de l’arbre 2167a4934d0a4a7db0de et de son parent d7042abb4821d3faf600. Est-ce que ça veut dire? Je devrais être capable de comprendre les choses assez rapidement sans avoir à consulter de la documentation étrange.
En parlant de documentation, du moins quand je l’utilisais, il me semblait que tout était au format de fichier man Linux, c’est déroutant et inutile pour moi. J'ai rarement pu trouver beaucoup d'aide dans la documentation et tout simplement eu recours à Google.
Et avec les commits, la seule chose qui ne me plaisait pas était le manque de numéros de version. Maintenant, je sais que cela est dû à la conception de git, mais tout logiciel nécessite un numéro de version. Je me souviens encore des commits de marqueur qui apparaissaient en disant "Version modifiée à 1.8.6" ou quelque chose de similaire, mais vous ne pouviez toujours pas créer de numéros de build. Pour moi, avoir la version 1.8.6.5164 (la dernière partie est le numéro de révision) me dit beaucoup plus que simplement 1.8.6 et une note disant que quelque chose de mineur a changé, essayez-le.
Étant donné que le logiciel est spécifique au logiciel, le programme de base sous Windows est msysgit, qui est une interface terrible. Il m'a bloqué à quelques reprises, avait une interface horrible et l'intégration CLI-GUI était au mieux douteuse. Les drogués de la ligne de commande autour de moi détestaient encore plus l'interface graphique.
Regardons maintenant SVN. Et depuis que je suis sur Windows et que j'ai un compte Google, en particulier TortoiseSVN et Google Code.
Premièrement, intégration complète du shell pour tout faire sur le référentiel (et pour vous linux, RabbitVCS fait la même chose), aucune interface graphique principale n’est nécessaire. Obtenir un référentiel est facile comme une caisse, pas besoin de SSH (je ne me souviens pas si Github a besoin de SSH pour les pulls), et pas de repo complète + tous les commits passés assis sur votre disque dur.
S'engager est extrêmement facile, principalement parce qu'aucune SSH ou mise en scène n'est requise. Il vous suffit de cocher tous les fichiers souhaités à l’aide de l’option très utile Sélectionner tout qui n’était pas disponible dans la version msysgit, de saisir un message de validation et de cliquer sur commit. Google Code vous demande ensuite vos informations de connexion (stockées par la plupart des clients), et ce que vous avez terminé. Simple, facile et sans SSH
Numéros de version? Avec un code simple, vous pouvez ajouter un numéro de version et un numéro de validation à toutes les commandes, ce qui simplifie grandement les choses. Vous obtenez également des numéros de version utilisables qui indiquent réellement une modification, par exemple 1.8.6.5165 est plus récent que 1.8.6.5164.
Documentation? Eh bien, c'est difficile à dire. La tortue est documentée, mais je n’ai pas fait référence à la documentation officielle depuis si longtemps que je ne peux pas en juger. Lire un simple guide d'introduction me suffisait.
La fusion est quelque chose d'autre que je ne peux pas comparer. Je devais le faire une fois dans Git lorsqu'un tiers modifiait un fichier sur lequel je travaillais, mais jamais dans SVN.
Lequel pourrais-je recommander? Bien dans les grandes équipes, git a ses avantages, principalement dans son cycle de développement non linéaire. Dans un autre projet, 4 programmeurs ont démarré dans des branches distinctes, puis ont fusionné tout le code de manière très étrange qui s'est en quelque sorte transformée en branche principale finale. Github et msysgit avaient un très bel outil de visualisation pour l’ensemble du projet que j’ai vraiment aimé.
Pour les projets à développeur unique ou de petite équipe, SVN serait le meilleur, car la plupart des fonctionnalités de Gits ne sont pas utilisées et vous obtenez uniquement ses aspects négatifs. La simplicité est une belle chose
