ptit_tux a écrit 1268 commentaires

Les plantage gdb, ça existe, c'est évidant. Mais c'est pas hyper courant. En tout cas, pour moi c'est rare.

Peut-être que chez toi ça plante et pas chez eux. Car t'as un configuration particuliaire ou autre. Comme tu peux savoir ?

> Si ils ne s'en sont pas rendu compte eux-même, c'est pas la peine de leur envoyer un bug report.

C'est pas le contraire que tu veux dire ?

Tu aurais du au moins contrôler si le bug est déjà renseigné :
http://sources.redhat.com/gdb/bugs/(...)

Installer subversion sans la partie serveur est facile. Tu peux créer un dépôt local (svnadmin create file://path/ ).

Je te conseille vivement de lire la doc de subversion (excellente même si elle est un peu longue pour un débutant).

Pour l'installation, il y a des paquets :
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=(...)

rh 9 est livré avec subversion 0.17 . Mais il n'y a pas la partie serveur (tu peut toujours créer un dépôt local). Ça permet de mettre le pied à l'étrier.

> les graphistes majoritaires.

Regardes de ce côté là. Ça tourne aussi sous Windows :
http://rapidsvn.tigris.org/(...)

Si c'est pour de la production, veilles à faire des dumps (svnadmin dump). C'est le dump est fait référence pour les montées de version (c'est comme postgresql).

> genre templates, et re-essaie gdb dessus.

Pour les templates, d'accord c'est pas top.

> Dernièrement on arrivait à faire crasher gdb lui-même.

T'as fait un rapport de bug ?

> C'est pas vraiment un secret que gdb digère mal C++.

Tu connais mieux ? T'as déjà utilisé xdb par exemple. Même pour du C c'est une ""horreur"".

> Oula, ca tourne au troll à deux balles là :)

C'est clair. J'avais envis que ça dégénère un peu. J'étais "correct" depuis le début, mais j'avais une petit envie d'un pétage de plomb sans rien vérifier. Je l'avoue, j'y connais rien ou presque en KDE.

> Vas y c'est la, je le merite le [-], ca te soulagera peut etre ;-)

Premièrement, je ne vote jamais à un post où je fais une réponse. Si je répond, utiliser en plus les votes, c'est abuser. De plus je n'ai pas de vote actuellement...

> La moidre des corrections serait de t'excuser.

Non. Il a clairement et volontairement mit des phrases pour dénigrer Subversion :
- "Le projet Subversion qui vise à remplacer CVS fait du sur place."
- "Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS."
- "A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués."

Si tu connais Subversion tu ne peux que conclure que c'est des conneries.

Je code majoritairement à C. Le C++ j'en fais parfois. J'ai commencé en 97 (sous Linux :-)). Inutile de faire une guerre de religion C/C++, j'adore le C++.

Sinon en quoi gdb est une "daube" pour le C++. Du moment que c'est compilé avec -O0 et -g2 ça passe parfaitement.

> La libxml n'est pas gnome

Pardon, c'est maintenant libxml2. Et à l'origine c'était gnome-xml. Puis libxml, c'est pas hébergé par gnome ? Oui.

> KDE n'utilise pas pango.

Vérifie. Il n'ont pas de fonctionnalité type pango alors...

> Qt est GPL

Sauf sous Windows.

> KDE avait l'anti-aliasing bien avant Gnome.

Prouve le.

s/conhérent/cohérent/

Pardon.

Sans raison je ne suis pas d'accord (relis).
Si c'est car il est "agressif et insultant" je t'en veux pas.

Voilà un discours conhérent.

> Subversion cherche à remplacer CVS

C'est vrai. Mais il faut "éclairer" ce point. Subversion ne veut pas remplacer CVS par un équivant à 100 % (je sais t'aime pas les pourcentage). C'est remplacer CVS dans la communauté du logiciel libre. CVS est très utilisé et est pratiquement seul dans le LL (ça change petit à petit avec le déploiement de subversion : http://svn.debian.org/(...) ). CVS est veillissant et il faut le remplacer. Remplacer CVS par un équivalent de CVS n'a aucun sens. Il faut faire mieux. Après il ne faut pas oublier les habitudes de la "communauté" et introduire des incompatibilités gratuite à CVS ou ne pas permettre l'importation d'arbre CVS vers Subversion est une erreur. C'est volonté de remplacer CVS n'empêche pas l'inovation et Subversion le prouve.

Je suis parfaitement d'accord avec toi. Subversion et Arch, se nourrissent l'un de l'autre. Par exemple Tom Lord est (ou était) fréquament sur la mailing list de Subversion.

> Chiche !

Heu, non. Là je suis à la bourre. Mais rapidement il y a les hooks côté serveurs (pour authentification par répertoire, et plein d'autre goodies), l'abstraction de stockage (utilisation futur de SQL), la copie de référence dans le dépôt local, les backup à chaud (c'est actuellement un fonctionnalité db4 mais c'est aussi de fait dans postgresql). C'est des exemples et comme je connais pas parfaitement Arch ...

Et malgrès leur formidable avance depuis longtemps et alors que cette avance continue croitre car ils vont plus vite, KDE doit utiliser libxml de gnome, pango de gnome, n'as pas d'équivalent de gconf (lit la doc de gconf avant de dire que les fichier .ini de kde c'est la même chose), doit utiliser un toolkit développé par une boîte proprio, commence timidement à avoir de l'anti-aliasing, va probablement reprendre gstreamer, etc, etc.

J'adore ton humour.

Je pose la question à Raphael Junqueira.
Sinon j'adore ton humour :
> vu le support C++ de gdb, c'est un peu normal

Les autres, eclipse, kdevelop, kdbg utilisent gdb. T'es vraiment un comique toi.

Le gus qui vote [-] à mon post, devrait lire attentivement mon post et la doc de subversion avant !

C'est ici :
http://svnbook.red-bean.com/html-chunk/(...)

Pour une présentation c'est ici :
http://subversion.tigris.org/files/documents/15/702/Subversion-Blai(...)

Le reste de la doc est ici :
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=(...)

Regarder à Design, Book, HowTo, Presentations.

Si vous votez [-] à cause des insultes, j'ai rien contre.

Tu es quand même marrant toi. 95 % des fonctionnalité de Arch sont dans Subversion. Il y a 5 % plus dans Arch par rapport à Subversion et 5 % dans Subversion par rapport à Arch et je suis très généreux. Le tar.gz de svn fait dans les 9 Mo et Arch 2,8. De plus Subversion s'appuis sur d'autres composants comme libapr, neon, db4, webdav et les 9 Mo c'est sans les interfaces graphiques. Et en fouillant rapidement je doit très, très, très facilement trouver des fonctionnalités/caractéristiques dans Subversion qui ne sont pas dans Arch.

Conclusion pour toi : Subversion n'est qu'une copie de CVS et d'un classicime rébarbatif alors que Arch est révolutionnaire. Faut pas pousser.

> Donc au niveau représentatif, cette page est assez proche du 0 pour moi

De 0 faut pas poussé. Les plus gros projets sont devant. C'est pas un hazard.

> >C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.

> Je n'ai jamais avancé de tels propos. Inventes ce que bon te plais. j'ai juste dis que "Subversion se positionne comme LE successeur de CVS".

La phrase exacte est :
- "Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS."

Lis ton article s'il te plait.

> 2/ Relis la page de tigris, les features vraiment novatrices sont pour "l'après 1.0" qu'on attend si patiemment. Et toi même tu l'avoues.

les "features vraiment novatrices" par rapport à CVS sont avant la version 1.0 (atomicité, gestion des répertoires, versionning de branche, coût 0 des copies, meta-donnée). Tu confirmes j'espère ?

> T'as un problème familial ? Des soucis dans ta vie de couple ?

Je bande mou.

> Depuis quand ne pas être d'accord avec quelqu'un

Qu'Edouard Gomez ne connaisse pas Subversion n'est pas critiquable. Qu'il n'aime pas Subversion non plus. Par contre attaquer subversion comme il le fait (avancer des allégations fausses etc...) et une démarche clairement volontaire de nuire. C'est ça qui m'énerve. C'est la démarche volontaire de nuire au projet Subversion.

> autorise à être incorrect, malpoli, grossier, tout ça en une seule fois ?

Non. Je l'ai fais sans autorisation.

Excellent. Ce n'est pas totalement représentatif mais ça évitera les "KDE va bien plus vite que Gnome".

> c'est GNOME qui a la plus grosse

Alors que c'est un gnome, elle doit trainer parterre.

> Sinon d'un point de vue exterieur, je t'assure que Kde progresse bien plus vite que gnome

On entend ça depuis des centaines d'années au minimum. Toujours le même disque.

Note bien que je ne dis pas que Gnome c'est mieux que KDE ou qu'il vont plus vite ou autre. Mais il faut toujours qu'un pro-KDE se la ramène dans une news Gnome pour dire KDE va plus vite que Gnome ou autre connerie dans ce goût comme tu viens d'en faire la démonstration.

> Sinon pour arts c un peu Normal que ca utilise pas Kde car c une fondation de celui-ci :)

C'est un service arts, un serveur. Tu peux installer une applis KDE sans arts. Idem pour Gnome avec esd.

J'oubliais : j'ai rien contre arch.

> Le projet Subversion qui vise à remplacer CVS fait du sur place.

N'importe quoi.
Regardes ici :
http://subversion.tigris.org/servlets/SummarizeList?listName=svn(...)

Cette mailing stocke les commits de subversion. globalement le rythme n'a pas changé.

Subversion est en phase beta. C'est pas la bonne période pour faire des inovations. De plus Subversion est de plus en plus utilisé et ce n'est pas non plus de moment de tout casser. L'objectif c'est la version 1.0 puis les inovations seront de retour.

NON et NON et NON subversion ne fait pas du sur place.

> Mais Subversion n'offre et n'offrira dans un futur proche presque rien de plus que CVS.

Excuse moi mon cher Edouard Gomez, mais tu es un con. Si tu t'étais renseigné 2 secondes tu aurais vu que ce que tu apprécies sur arch, existe sur subversion :
- les commits sont atomiques. C'est du versionnage de branche et non uniquement de fichier
- subversion ne se limite pas au fichier, il reconnait aussi les repertoire, tu peux les renommers, etc... Par contre la gestion des liens symboliques sera pour après version 1.0.
- Dans subversion il y a aussi la copie à coût 0 (la création d'une branche étant une copie).
- Lorsque tu développes avec subversion, tu as un dépôt local où tu fais toutes tes opérations. Après du peut faire un commit vers le serveur.
- Subversion, le backend, est orienté base de données. Actuellement il utilise Berkeley DB mais après la version 1.0 d'autre base de donnée seront supporté (mysql/postgresql, etc).
- Subversion consomme peut de réseau. Seul les diffs circulent et en compressé.
- Subversion dispose déjà de client graphique qui tourne sous Unix et Windows.
- Subversion est très portable et basé sur la lib apr d'apache. Ainsi, Subversion tourne déjà pratiquement partout (Linux, Unix, Windows, Mac).
- Le protocol réseau de Subversion est parfaitement standard puisque c'est webDav. Tout client Dav peut fouiller un dépôt Subversion. Pour le serveur, Apache est utilisé (+ module dav + module subversion). C'est une garanti d'efficacité et de sécurité. C'est donc très facilement qu'https est dispo.
- etc

C'est "presque rien de plus que CVS" ? Subversion veut remplacer CVS mais au près des utilisateurs ! Ça ne veut pas dire que Subversion va recoder CVS ! Faut être con pour croire ça.

> A dire vrai, des projets comme meta-cvs, se greffant sur CVS, font presque aussi bien que Subversion tout en étant bien moins compliqués.

100 % pure troll.

Le point fort de arch par rapport à subversion est son modèle plus distribué. Subversion restant sur un modèle plus centralisé. Cependant, l'objectif premier de subversion est TOUS les developpeurs et non seulement les développeurs de Linux. Quoiqu'il en soit, les devs de Linux ne sont pas oubliés. Un nouveau format de patch existe et permet de s'échanger des patchs qui contient des infos sur le renommage de fichier, déplacement des répertoires, changement d'attribut (les meta-donné) etc... Donc il n'y a pas de problème, a moyen terme ,pour la version 1.2 ou 2.0, les developpements distribués ne sont pas oubliés. Les fonctionnalités 1.0 sont déjà suffisante pour la faire (faire un "appliqué les différence entre la version 100 et 242 du dépôt d'Alan Cox sur mon dépôt local (avec renommage, meta-data, etc)" par exemple).

C'est news c'est de la MERDE.

PS : NRV.

> C vrai que deja GVD c mieux, mais bon un debuggeur comme celui integre dans eclipse ou kdevelop sont nettement plus adapte a une utilisation sur de gros projets.

Finalement je crois que tu te fous de ma gueule. kdevelop utilise kdbg pour le debugguage. C'est vraiment pas au niveau de ddd. A côté de ddd, kdbg c'est ... oublions je ne veux pas être méchant.

Questions :
As-tu sérieusement utilisé ddd ?

N'as-tu pas honte de critiquer un projet alors que tu ne l'as pas utilisé ?

Si eclipse c'est du même niveau que kdbg, il y a pas photo, ddd reste le roi des debuggeurs et de très très loin.