ld-tigcc - Flash OS BSS Special - Page 5

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).

sf.net supporte le svn maintenant. Peut être que tigcc devrait y migrer? cvs est assez obsolète...

+1 pour une migration de TIGCC vers SVN.
SVN corrige l'aberration du commit non atomique, mais même avec sa surcouche SVK (que j'ai utilisée pendant plusieurs mois), il reste moins bon que de vrais DSCM.

Comment comptes-tu synchroniser avec mes commits dans ton miroir, étant donné la procédure compliquée que tu as utilisée pour le convertir?

Et tiens, j'ai retrouvé mon commit message préféré.
http://gitorious.org/projects/tigcc-linux/repos/mainline/commits/1e28ec2948b26d54f73862437d8a2c2af9a8d12a

squalyl (./122) :
sf.net supporte le svn maintenant. Peut être que tigcc devrait y migrer? cvs est assez obsolète...

Je ne vois pas l'intérêt, CVS fonctionne très bien.

ouais, d'accord...

Comment comptes-tu synchroniser avec mes commits dans ton miroir, étant donné la procédure compliquée que tu as utilisée pour le convertir?

* cvssuck pour la synchro incrémentale avec upstream. Déjà testé parce qu'il manquait quelques fichiers dans son premier import, heureusement que je me suis amusé à le relancer pour voir ce que ça faisait.
* cvs2svn (probablement avec un effacement intermédiaire du repository SVN et un trifouillage de l'UUID, je n'arrive pas à faire fonctionner --existing-svnrepos)
* git-svn fetch
* git-push

Naturellement, avec une conversion à SVN (je peux te fournir le repository SVN), les deux premiers pas sautent.

Fix yet another typo in Lionel's header file updates. Someone is mistaking TIGCCLIB for a junkyard for broken untested code.

Je ne connaissais pas ce message. Vilain
J'ai testé l'address hack lui-même dans mon fichier de tests, mais manifestement pas après l'avoir écrit sous cette forme dans le .hsf

Je ne vois pas l'intérêt, CVS fonctionne très bien.

Euh... nan. Le commit non atomique, que j'ai rencontré deux fois en utilisation normale, ça ne fonctionne pas. Un SCM qui n'assure même pas l'intégrité de ses données doit aller à la poubelle.

Quand il y a une seule personne qui fait des commits, atomique ou pas, on s'en fout un peu.

Même pas: CVS m'a déjà exhibé le commit non atomique dans le cas "1 seul commiter" (programmes de TICT) comme dans le cas "multiples commiters" (projet scolaire).
Si CVS se plante pour une raison ou une autre au milieu du commit, il laisse les fichiers déjà traités dans le nouvel état, et les fichiers pas encore traités dans l'ancien état. De mémoire (ça fait plus de deux ans que je n'utilise plus ce gros caca qu'est CVS...), tu ne peux plus aller en avant ni arrière. Une des façons les plus simples de repartir dans un état sain, au cas où CVS se fasse dessus, est de faire, avant chaque commit, une copie de ses répertoires.

Ca, c'est inadmissible pour un outil de gestion de sources.

[EDIT: si KDE et GCC, entre bien d'autres, sont passés à SVN ou mieux, c'est bien que CVS ne fonctionne pas si bien que ça...]

On renomme les fichiers touchés, on fait un cvs up (ce qui restaure les sources "perdues"), on remet sa version par dessus et on refait le commit.

Et il y a d'autres grands projets qui utilisent CVS, par exemple Fedora gère ses specfiles dans un CVS.

La honte... Fedora me fait vraiment de la peine.

On renomme les fichiers touchés, on fait un cvs up (ce qui restaure les sources "perdues"), on remet sa version par dessus et on refait le commit.

C'est une autre méthode, mais bon... , quoi. Ce genre de contorsions montre juste que CVS n'est pas à recommander pour des projets sérieux, même quand la taille du repository reste suffisamment faible pour que les performances ne s'en ressentent pas trop...

Et il y a d'autres grands projets qui utilisent CVS, par exemple Fedora gère ses specfiles dans un CVS.

vous fatiguez pas, vous parlez à un mur qui sortira tous les arguments ad-hoc pour rester sur sa position

sinon +1 pour cvs.

Je vais vous raconter une petite histoire, qui s'est réellement produite: il était une fois un dépôt pour paquetages non officiels, nommé http://rpm.livna.org/. Ce dépôt utilisait SVN. Or, maintenant, ce dépôt est en cours de fusion avec quelques dépots plus petits, pour le projet rpmfusion. Et le nouveau dépôt utilisera... CVS!

Bref, il y a même des personnes qui passent de SVN à CVS.

les pauvres

+1 ./133...

Quant à ./134... #vomi#

Sérieusement, quel a bien pu être le processus de décision pour passer de SVN à CVS ?? Ca signifie:
* une efficacité de stockage et de transfert diminuée (CVS ne fait pas des transferts différentiels dans tous les cas);
* la réapparition du commit non atomique;
* la réapparition du checkout partiel, conséquence du commit non atomique, qui permet d'obtenir une superbe working copy qui peut ne pas compiler parce qu'une partie des fichiers est toujours à une ancienne révision;
* l'utilisation du tagging affreux de CVS, qui doit modifier tous les fichiers du repository... Le tagging de SVN est aussi plutôt mauvais (la bonne solution étant la simple utilisation d'une étiquette, cf. les DSCM), mais il est plus clean et plus efficace que celui de CVS.

Ca leur fait une belle jambe, mais Fedora baisse dans mon estime... Je n'utilise jamais et ne recommande jamais cette distro à cause de son extrémisme "pure free software race" que je ne pense pas être la bonne façon de procéder pour gagner des utilisateurs... mais en plus, si les développeurs Fedora eux-mêmes indiquent que le projet est "organisé" complètement en dépit du bon sens, alors là...
J'espère que RedHat, pour produire un résultat de qualité professionnelle, n'utilise pas ce type de méthodes.

De mon point de vue, si un projet pro pense déjà à utiliser CVS, je suis vraiment content. Parce que franchement, au vu de mon expérience, ...

Vu comme ça...
CVS, c'est évidemment un progrès par rapport à rien, mais on peut faire tellement mieux...

Lionel, je te signale que ce sont des dépôts pour paquetages, donc la plupart du temps, les commits ne touchent qu'un (specfile) ou deux (specfile et un patch) fichiers, alors des commits atomiques, on s'en contrefiche. Et les tags ne sont effectués que dans le répertoire d'un paquetage pour une distribution, donc sur très peu de fichiers à la fois. L'organisation est par répertoires paquetage/branche (où "branche" = version de la distribution) et les branches natives CVS ne sont utilisées qu'à l'intérieur de ces "branches" si un mainteneur veut tester quelque chose tout en pouvant sortir des paquetages basés sur la version stable.

CVS fonctionne très bien en pratique, quoi que tu en dises.

mouais. menfin bon, tout ce qui augmente la sécurité du code est bon à prendre.

mais c'est pas ton cheval de bataille, je sais.

sinon y'a pire, y'en a qui utilisent clearcase

J'ai bien compris que c'était un repository de packages. C'est justement un cas d'utilisation tellement trivial que les bugs / limitations de CVS ne font pas grand mal.
Mais je me pose quand même des questions sur le bien fondé de ce choix... surtout que contrairement au projet Mozilla, là, ils se foutent complètement que ça fonctionne sous Windows (où les DSCM fonctionnent moins bien à cause de la lenteur de l'appel équivalent à stat(2)).

CVS fonctionne très bien en pratique, quoi que tu en dises.

Ecrite de la sorte, cette affirmation péremptoire est parfaitement ridicule, voir plus haut pourquoi. Ca irait mieux avec une nuance comme "fonctionne très bien POUR CE PROJET".


Bon, si on arrêtait sur les (D)SCM ? Comme l'a déjà écrit squalyl en ./133, on sait bien que ce n'est pas cette discussion qui nous fera changer de position.

Et pour résumer ./121 et la suite: depuis avant-hier, un miroir Git de TIGCC existe. N'importe qui peut le cloner; commiter des patches (en attente de traitement par upstream ou pas, voire des patches rejetés) sur le clone; publier le clone (pour test par des tiers, pour pull par upstream éventuellement un jour, etc.).
Si vous préférez SVN, il est parfaitement possible de créer un miroir. Il faut juste trouver un hébergeur: opensvn.csie.org est gratuit, mais il est victime de son succès, il est lent.
Si vous préférez d'autres (D)SCM, il existe un certain nombre de convertisseurs.

Bon, je reviens sur les (D)SCM
Mais c'est seulement pour indiquer que j'ai effacé et recréé le miroir Git au même endroit, parce que:
* ce que j'avais créé ne disposait ni de tags ni de branches Git;
* Kevin a ajouté un tag antérieur à HEAD sur le repository CVS, cvs2svn change donc l'historique des commits.

Maintenant, j'ai ajouté des tags Git au même niveau que les "tags" ajoutés par cvs2svn (remotes/tags/*), et j'ai ajouté la branch Git ktigcc-1-branch.

Je pense que j'ai compris comment ajouter les nouvelles révisions de CVS (tant que l'historique n'est pas cassé par un tag antérieur à HEAD):
* faire générer un dumpfile à cvs2svn;
* effacer du dumpfile les révisions déjà présentes dans le repository SVN;
* svnadmin load;
* git-svn fetch.

je te trouve super patient ##trilangue##

Bof, c'est l'affaire de quelques minutes à chaque jeu de commits (sans compter le temps pris par cvssuck)
En fait, ça doit tout être scriptable:
* le dumpfile est un format très facile à parser (c'est un des buts de conception de SVN), donc l'effacement dans le dumpfile des révisions déjà présentes dans le repository est faisable;
* la détection de la casse de l'historique des commits peut être faite en comparant l'ancien dumpfile et le nouveau. Sauf que ce sont de gros fichiers: le dumpfile généré par cvs2svn n'est ni différentiel ni incrémental, il consomme actuellement un peu moins de 140 MB (5 fois moins compressé avec gzip, 10 fois moins avec bzip2). Je vais faire le gros des traitements dans le tmpfs monté en RAM, ça ira plus vite.

Ce qui est bien avec Perl, c'est que si on a besoin de faire un truc, c'est loin d'être improbable que quelqu'un l'ait déjà fait et mis sur CPAN
Ici, c'était SVN :: Dumpfilter qu'il me fallait pour faire un code plus propre (quoique plus lent) qu'un code trivial à base de
split /Revision-number:\ /
qui consomme beaucoup de mémoire...

[EDIT: suppression d'un smiley intempestif]
[EDIT2: script testé en vraie grandeur (plutôt qu'avec des dumpfiles locaux simples, je veux dire) avec les trois derniers commits de Kevin sur le repository (transformés en 4 commits car l'un touche les deux branches), propagés sur le repository sur Gitorious.]

J'imagine que personne n'a eu le temps de s'amuser à implémenter l'utilisation d'arbres équilibrés à la place de l'utilisation de listes chaînées ?

Pas moi.

Moi non plus.

huhu

Je viens de le commiter !
































nan je déconne !