De nombreux projets ayant basculé sous SubVersion ces derniers mois, j'en ai déduit que cet outil était arrivé à matûrité et j'ai donc décidé de l'essayer à mon tour.
La première impression est très positive mais :
* Bien qu'annoncé comme le fils spirituel de CVS, Subversion requiert un certain temps d'adaptation car certains aspects sont traités de manière très novatrice pour un adepte de CVS.
* Subversion peut stocker les fichiers dans une base Berkeley DB ou dans son propre « système de fichiers », FSFS. L'expérience m'a montré que les droits d'accès sont problématiques avec une base Berkeley DB dans un contexte multi-utilisateur. D'ailleurs, dans le livre « Version Control with Subversion », il est conseillé d'utiliser dans ce cas un espace de stockage de type FSFS.
* Les répertoires administratifs .svn contiennent deux copies de chaque fichier importé dans le référentiel. Cela permet d'effectuer des diffs et d'autres opérations en local et présente de sérieux avantages. En contrepartie, la copie de travail du projet s'avère donc 3 fois plus volumineuse que les sources originelles. Quelqu'un a dit que le projet KDE représentait 15 Go de sources. Pour importer une copie de travail intégrale du projet, il faut donc prévoir 45 Go d'espace disque !
Mais une fois ces problèmes assimilés, il est vrai que Subversion a de nombreux atouts pour séduire, à commencer, pour moi, par les commits atomiques, la gestion des répertoires, le renommage et le déplacement de fichiers sans perte de l'historique.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Sébastien Dinot (site web personnel) . En réponse à la dépêche Le basculement de KDE vers Subversion est terminé. Évalué à 1.
La première impression est très positive mais :
* Bien qu'annoncé comme le fils spirituel de CVS, Subversion requiert un certain temps d'adaptation car certains aspects sont traités de manière très novatrice pour un adepte de CVS.
* Subversion peut stocker les fichiers dans une base Berkeley DB ou dans son propre « système de fichiers », FSFS. L'expérience m'a montré que les droits d'accès sont problématiques avec une base Berkeley DB dans un contexte multi-utilisateur. D'ailleurs, dans le livre « Version Control with Subversion », il est conseillé d'utiliser dans ce cas un espace de stockage de type FSFS.
* Les répertoires administratifs .svn contiennent deux copies de chaque fichier importé dans le référentiel. Cela permet d'effectuer des diffs et d'autres opérations en local et présente de sérieux avantages. En contrepartie, la copie de travail du projet s'avère donc 3 fois plus volumineuse que les sources originelles. Quelqu'un a dit que le projet KDE représentait 15 Go de sources. Pour importer une copie de travail intégrale du projet, il faut donc prévoir 45 Go d'espace disque !
Mais une fois ces problèmes assimilés, il est vrai que Subversion a de nombreux atouts pour séduire, à commencer, pour moi, par les commits atomiques, la gestion des répertoires, le renommage et le déplacement de fichiers sans perte de l'historique.
Sébastien