#3588 a écrit 2279 commentaires

« Non, mais la connerie, c'est de faire le tar xf sans avoir fait le tar tf. »

Pour ça on est d'accord...

« Et si le fichier tar contient des sous-répertoires, tu les laisse en vrac ! Si tu veux vraiment supprimer la m**** mise par le tar, il faut bien le -r. »

Non, en deux étapes, après le rm -f des fichiers, un « rmdir -p * » (qui au passage nettoie tes répertoires inutiles) ou truc du genre. C'est quand même très différent.

L'auteur de BitKeeper travaillait sur Linux avant (et maintenant encore sans doute), il connaissait bien Linux et les problèmes de gestion de version spécifiques au développement du noyau. BitKeeper a été quasiment fait pour Linux (évidemment il convient pour d'autres projets) et c'est normal qu'il se soit retrouvé comme "meilleur" outil pour Linux (indépendamment de l'aspect libre). L'auteur a misé sur la réputation qu'il obtiendrait en étant retenu, il y a consacré du temps, et pour rentabiliser ce n'est pas libre. Mais si le critère libre avait été imposé dès le départ (si Linus avait dit que toute gestion de version devait se faire avec du libre) ce logiciel n'aurait a priori pas été créé.

Personnellement j'ai eu affaire à Ant, qui semble très bien (ceux qui l'utilisent en tant que développeurs sont en général enthousiastes) mais qui doit être présent sur la machine où se fait l'installation. Et comme il nécessite Java, j'avais trouvé ça très pénible (évidemment c'est moins genant pour ceux qui ont déjà Java).

« Etre libre, n'est-ce pas aussi la possibilité de choisir d'utiliser des logiciels libres et/ou open-source ou non-libre et/ou fermés ? »

Etre libre sans doute, mais quel rapport avec « logiciel libre » où libre qualifie le logiciel, et le rapport entre un utilisateur et le logiciel ?
Pourquoi le caractère non libre ne pourrait pas suffire à empecher un logiciel d'etre parfait ? « parfait » c'est quand même pas rien...

Finalement, comme l'a dit quelqu'un d'autre, tout ce qu'il y a d'intégriste, c'est ton discours ("vous pensez pas comme moi, donc vous êtes intégristes, disparaissez." très ouvert...)

« CVS qui commence à être largement dépassé (Attention, troll detected) »

Ce n'est pas un troll, je pense que quasiment tout le monde est d'accord là dessus. Le problème c'est d'avoir des alternatives fiables (on doit y être tout juste) et répandues (sur les sourceforge-like notamment).
C'est comme les autoconf/automake etc. Ça reste les meilleures solutions pour différentes raisons mais par bien des côtés ils sont « dépassés ». Dans leur cas il y a des alternatives mieux conçues mais qui ont d'autres inconvénients (par exemple des dépendances vers autre chose que make pour l'utilisateur final).

Dépôt et fusionner oui, commettre c'est quand même pas terrible... Dans ton lien ils proposent enregistrer, c'est mieux mais ça peut porter à confusion... Appliquer me paraît mieux. Quelqu'un voit d'autres candidats ?

une expression ne se traduit pas mot à mot...

« Alors quand on poste un commentaire qui dit que RMS est completement barjot et que ses idees vont trop loin et peuvent meme nuire au logiciel libre, on prend -5 voire -10. »

C'est normal puisque tu démontres par la même occasion que tu n'as strictement rien lu de ses discours. Et critiquer quand on ne sait pas de quoi on parle, ça n'est pas très constructif, ça ne fait pas partie des posts à mettre en avant dans une discussion.

Pour m'exercer je vais d'abord faire une news sur WindowMaker 0.70.0 (ah, la bonne époque !)

Peut-être qu'on les trouve dans des jargons spécifiques, mais en général ces mots sont introduits avec un pluriel francisé, et ce n'est que bien après que des pompeux se proposent d'utiliser un pluriel pour montrer qu'ils connaissent l'origine de ce mot.
En plus des virus et unix que tu donnes, je pense à scénarios, médias, forums (eh oui, certains vont dire des « fora », on peut difficilement faire plus pédant !)

Et puis je rajoute une petite remarque : il ne faut pas oublier que 2.6.2 et les premiers de la branche 2.6 vont être ceux qui vont se retrouver dans les premieres distribs à fournir du 2.6. Certes fortement patchés par les distributeurs, mais c'est bien sur ces versions et sur le retour qui va être fait que la prochaine série de distribs va être basée...

Si tous les noyaux stables étaient annoncés, ça n'en ferait qu'un toutes les 6 semaines en moyenne. Je me demande pourquoi regarder un site de news Linux si ce rythme est si insupportable. J'espère que le rythme d'une news tous les 3 ans (ce que tu prénonises) n'est pas trop violent non plus...

D'ailleurs en s'imposant ce rythme d'une news tous les 3 ans, ce sont bien les changements de numéro majeur de KDE qui devraient être annoncés, et pas en dessous.

Je pense que LinuxFr peut largement passer les deux sans que ça innonde la première page...

Non ton ficher README a été perdu lors du tar. Laisser celui qui l'a écrasé ne va pas faire revenir l'original.
Et puis, c'est un rm -f, pas un rm -rf.

Peut être que c'était pour dire que Firebird 0.8 n'est pas encore sorti.
Tiens je vais faire un journal sur gcc 3.4 moi...

Oui, à propos des branches, il y a maintenant la possibilité de faire des merge consécutifs (avec CVS le diff est appliqué 2 fois si on ne prend pas garde).

« Mais pourquoi avoir redévellopé un truc plutot que d'avoir ajouté ces optimisations directement dans CVS ???? »

Parce que ce ne sont pas juste des optimisations ! Si ça avait été possible avec CVS, je crois que l'équipe de CVS l'aurait fait depuis longtemps. On est vraiment dans un de ces cas où les fonctionnalités voulues nécessitaient une réécriture complète.

Je n'ai jamais essayé, ça ne me semble pas une bonne pratique.
Si le fichier que tu as modifié n'a pas été modifié par quelqu'un d'autre, il doit l'accepter (éventuellement en disant bien de ne commiter que celui-là). Mais il me semble préférable de faire un update, vérifier que tout marche toujours, puis commiter, je pense qu'avec ce que tu proposes on peut se retrouver avec une version "courante" dans le repository qui ne compile plus.

Il n'a pas dit que c'était spécifié dans le langage mais qu'on pouvait en faire.
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html(...)

Non c'est juste "Not" (seul) qui mène à Gnu's Not Unix. Il n'y a pas beaucoup de sites aussi référencés que GNU à avoir "not" dans leur titre.

Je me suis peut-être mal exprimé, mais d'après tes 2 descriptions de fusion/écrasement, CVS fait plutot de la fusion : plusieurs personnes peuvent faire des modifications en même temps. Le commit se fait en deux commandes : update + commit, les conflits de fusion étant à régler suite à l'update, s'il y en a.

Dans le cas simple où il n'y a pas de conflits (modifs dans des fichiers différents ou des endroits bien séparés), tout le monde peut travailler en même temps et à partir de la même version, puis chacun fait un update+commit qui se passera bien. Quel que soit l'ordre des commits, toutes les modifs seront cumulées dans la version "actuelle" du serveur.

« Quand a la "pale copie", la plupart des developpeurs de jeu pensent aujourd'hui le contraire, les dernieres versions de DirectX on depasse OpenGL. »

Le pauvre, il délire complètement maintenant.

« Ca aurait été interessant d'apporter qqes "vraies" nouveautés non ? »

Gestion des répertoires et commit atomiques, ça ne me paraît pas de "petites" nouveautés...

« deplacement de fichiers, faut pas pousser, ca se fait trés bien, sans "magouille" sur le serveur »

Ben non. « Sans magouilles » ça veut dire avec des commandes CVS, et sans toucher au repository à la main.
De plus même avec cette magouille ça marche mal puisque l'historique est cassé là où tu fais cette opération : elle n'est pas mémorisée dans l'historique du projet global.

« Ca n'est pas ma solution mais celle préconisée par les auteurs de CVS; si c'est tu trouves ca nul, tu peux leur dire »

Ils le savent, les défauts de CVS sont connus et reconnus, mais tout résoudre revient à reprendre tout à zéro. C'est ce que fait l'équipe de Subversion. Quant à CVS il reste très utile, très stable, il est juste important d'en connaître les limitations et de ne pas s'imaginer qu'on peut tout faire avec en bidouillant le repository.

Le fichier du serveur n'est ni écrasé ni fusionné, ou alors je ne comprends pas ce que tu signifies par là. Le fichier est modifié de manière à contenir la version commitée + les diffs inverses pour refaire l'historique. Concernant la fusion, CVS ne le fait pas lors du commit. Il faut que la version à commiter soit "à jour". Donc la procédure c'est de mettre à jour son répertoire de travail (c'est là qu'est fait l'éventuel travail de fusion), qui est alors prêt à être commité. Si quelqu'un a commité juste avant toi et que ça pose problème, CVS ne te laisse pas commiter, il faut que tu refasses une mise à jour et le travail de fusion.
Ca ne nécessite pas de verrous (mais il y a quand même possibilité d'en mettre).