Le but avoué de Subversion est de proposer un remplaçant à CVS. Le projet à été lancé au début de ce siècle, par le groupe qui représentait les derniers mainteneurs actifs du code source de CVS, et qui étaient donc dans une position idéale pour juger des faiblesses de CVS et les corriger. L'un des fondateurs de Subversion, Karl Fogel, a écrit un livre sur l'utilisation de CVS qui est une référence sur le sujet.
Quant à la remarque sur l'utilisation intensive du branch/merge, j'avoue ne pas comprendre, a moins que tu n'aie jamais utilisé CVS. La gestion des branches dans CVS est l'une des pires facettes de ce logiciel. J'admets, il n'y a pas encore de merge tracking intégré à Subversion, mais d'un autre coté, dans CVS non plus. C'est un affreux hack qui ne garantit en rien l'intégrité des données. Le développement du merge tracking dans Subversion avance, et en attendant, l'outil svnmerge.py implémente les trois quarts de ce qui est nécessaire pour le commun des mortels de ce coté là.
OpenCVS, sans vouloir lancer de troll, je me demande si ca servira à quiconque autre qu'OpenBSD. Rester coincé sur la compatibilité avec "l'outil d'avant" est l'erreur que CVS a fait en se basant sur RCS, et RCS sur SCCS. Ils ont trainé des erreurs de conception sur plus de 20 ans avec ce principe, et OpenBSD veut maintenant les perpétuer dans son propre projet.
Ce n'est pas pour rien à mon avis que tant de projets se détachant du code de CVS sont nés. CVS est dans l'impasse depuis 2000, mis a terre par sa compatibilité ascendante à outrance, trainant plus de 20 ans d'erreurs, refusant obstinément de changer pour préserver une compatibilité qui n'a plus lieu d'être. Le monde s'est rendu compte que c'était une impasse, et a commencé a bosser sur d'autres produits: bitkeeper dans le monde propriétaire, et une constellation d'outils dans le monde libre. Bon sang, les développeurs les plus actifs de CVS à l'époque ont déserté pour écrire Subversion, ça devrait envoyer un message clair!
Concernant les autres outils existants, moi je dis bravo. Gits, TLA, Mercurial, Darcs, Codeville, tout ca, bravo. Ce sont des projets intéressants, plus ou moins avancés, mais intéressants. Ils cherchent tous à faire avancer le monde en proposant des outils performants, et font avancer la théorie du revision control en général. Et ils n'ont pas peur de dire "Non, on ne va pas etre compatible avec le format de dépot tout à fait pourri de CVS. On va oser changer la tronche de l'interface utilisateur, parce qu'on pense pouvoir faire mieux."
Désolé de m'emporter, mais en tant que développeur et passioné d'outils de revision control, CVS m'a traumatisé, et le fait qu'on puisse en 2006 prétendre que cet outil à un avenir autre que la casse me fait voir rouge.
[^] # Re: OpenCVS
Posté par David Anderson . En réponse à la dépêche Subversion 1.4.0 est disponible. Évalué à 10.
Quant à la remarque sur l'utilisation intensive du branch/merge, j'avoue ne pas comprendre, a moins que tu n'aie jamais utilisé CVS. La gestion des branches dans CVS est l'une des pires facettes de ce logiciel. J'admets, il n'y a pas encore de merge tracking intégré à Subversion, mais d'un autre coté, dans CVS non plus. C'est un affreux hack qui ne garantit en rien l'intégrité des données. Le développement du merge tracking dans Subversion avance, et en attendant, l'outil svnmerge.py implémente les trois quarts de ce qui est nécessaire pour le commun des mortels de ce coté là.
OpenCVS, sans vouloir lancer de troll, je me demande si ca servira à quiconque autre qu'OpenBSD. Rester coincé sur la compatibilité avec "l'outil d'avant" est l'erreur que CVS a fait en se basant sur RCS, et RCS sur SCCS. Ils ont trainé des erreurs de conception sur plus de 20 ans avec ce principe, et OpenBSD veut maintenant les perpétuer dans son propre projet.
Ce n'est pas pour rien à mon avis que tant de projets se détachant du code de CVS sont nés. CVS est dans l'impasse depuis 2000, mis a terre par sa compatibilité ascendante à outrance, trainant plus de 20 ans d'erreurs, refusant obstinément de changer pour préserver une compatibilité qui n'a plus lieu d'être. Le monde s'est rendu compte que c'était une impasse, et a commencé a bosser sur d'autres produits: bitkeeper dans le monde propriétaire, et une constellation d'outils dans le monde libre. Bon sang, les développeurs les plus actifs de CVS à l'époque ont déserté pour écrire Subversion, ça devrait envoyer un message clair!
Concernant les autres outils existants, moi je dis bravo. Gits, TLA, Mercurial, Darcs, Codeville, tout ca, bravo. Ce sont des projets intéressants, plus ou moins avancés, mais intéressants. Ils cherchent tous à faire avancer le monde en proposant des outils performants, et font avancer la théorie du revision control en général. Et ils n'ont pas peur de dire "Non, on ne va pas etre compatible avec le format de dépot tout à fait pourri de CVS. On va oser changer la tronche de l'interface utilisateur, parce qu'on pense pouvoir faire mieux."
Désolé de m'emporter, mais en tant que développeur et passioné d'outils de revision control, CVS m'a traumatisé, et le fait qu'on puisse en 2006 prétendre que cet outil à un avenir autre que la casse me fait voir rouge.