Ouai m'enfin dire que cvs c'est pas trop mal parce qu'il n'empêche pas d'utiliser git, c'est pas vraiment un argument pour rester avec cvs.
Il y a une raison toute simple : l'historique. On a un arbre cvs qui contient près de 20 ans d'historique et plusieurs centaines de millier de commits.
Migrer vers un autre VCS, pour OpenBSD, n'est acceptable que s'il est possible de récupérer la totalité de cet historique. Ce n'est pas du luxe, il arrive fréquemment que l'on aie à effectuer des recherches dans le code sur plusieurs années en arrière, et obliger à utiliser deux outils et deux arbres source selon la période concernée n'est pas acceptable.
On a essayé, par le passé, divers outils de migration de VCS afin d'étudier la possibilité de la chose. Par exemple, cvs2svn n'est pas capable de gérer un arbre aussi gros (aussi bien en consommation mémoire qu'en consommation CPU). Notre meilleur espoir est actuellement effectivement une migration vers git, et un des développeurs a écrit un script qui arrive à traiter tout l'arbre, et reconstruire de véritables commits (i.e. retrouver les fichiers qui font l'objet d'un commit cvs avec le même message et au même moment). Il y a encore quelques opérations cvs qui lui posent problème, cependant.
[^] # Re: Gestionnaire de source
Posté par Miod in the middle . En réponse au journal Des nouvelles de LibreSSL. Évalué à 10.
Il y a une raison toute simple : l'historique. On a un arbre cvs qui contient près de 20 ans d'historique et plusieurs centaines de millier de commits.
Migrer vers un autre VCS, pour OpenBSD, n'est acceptable que s'il est possible de récupérer la totalité de cet historique. Ce n'est pas du luxe, il arrive fréquemment que l'on aie à effectuer des recherches dans le code sur plusieurs années en arrière, et obliger à utiliser deux outils et deux arbres source selon la période concernée n'est pas acceptable.
On a essayé, par le passé, divers outils de migration de VCS afin d'étudier la possibilité de la chose. Par exemple, cvs2svn n'est pas capable de gérer un arbre aussi gros (aussi bien en consommation mémoire qu'en consommation CPU). Notre meilleur espoir est actuellement effectivement une migration vers git, et un des développeurs a écrit un script qui arrive à traiter tout l'arbre, et reconstruire de véritables commits (i.e. retrouver les fichiers qui font l'objet d'un commit cvs avec le même message et au même moment). Il y a encore quelques opérations cvs qui lui posent problème, cependant.