git-cvsimport n'est manifestement pas capable d'importer plusieurs modules en même temps, et c'était bête d'avoir 3 repositories différents pour les 3 modules (triple update, etc.)...
J'ai donc recommencé à zéro l'import:
* création d'un miroir du repository CVS en local, ce qui est très coûteux en temps (pour l'ordinateur, pas pour l'humain qui déclenche une seule commande et doit attendre que cela se termine, des heures après) et en trafic réseau;
* conversion vers un repository SVN en local;
* utilisation de git-svn init&fetch pour obtenir un repository Git.

Aujourd'hui, j'ai rendu public le miroir git obtenu à http://gitorious.org/projects/tigcc-linux (créé hier), parce que je sais que certaines capacités des DSCM, comme:
* la simplification de la gestion des patchsets locaux;
* le travail en mode déconnecté (j'ai vu, au boulot, la très mauvaise fiabilité d'un serveur SVN pendant quelques semaines - mon miroir local me permettait de regarder les logs de commits et de faire diff-edit-patch-commit entre branches, et éventuellement de rendre ce service à mes collègues utilisateurs de SVN, qui ne pouvaient pas bosser correctement...)
* le stockage beaucoup plus efficace que ces fichus ".svn".

peuvent intéresser d'autres développeurs que moi. Et c'est bête et lent de refaire le boulot.


Q: C'est un fork de TIGCC ?
A: J'affirme que le repository "mainline" à l'intérieur du projet "tigcc-linux", est un miroir, pas un fork. Il est totalement incorrect pour un fork de se prétendre "miroir".
Pour qu'il y ait fork, il faut qu'il y ait publication (j'ai du mal à donner du sens à la notion de "fork privé"...) de commits autres que ceux d'upstream.
Il est clair que si un fork voit le jour, les DSCM en faciliteront la maintenance et la diffusion... mais même si n'importe qui pouvait, depuis plusieurs années, utiliser le repository CVS Sourceforge, ou même simplement les snapshots source, pour faire un fork de TIGCC, personne ne l'a jamais fait (à ma connaissance).