« Peu de temps avant que nous ne partions tous en vacances de Noël, l'une des entreprises sponsorisant des développeurs dans la communauté Subversion, WANdisco, a envoyé un grand "fu#k you" au reste de la communauté par la voix de son CEO, Dave Richards », écrit Mark Phippard, l'un des principaux contributeurs sur son blog. Contexte : en 2009, le développement du système de contrôle de versions Subversion (SVN pour les intimes) est passé sous l'égide de la fondation Apache, après avoir été mené par Collabnet pendant des années (de nombreux développeurs de Subversion sont employés par Collabnet : C. Michael Pilato, Mark Phippard, Paul Burba ,pour ne citer qu'eux). Wandisco est une autre entreprise fortement impliquée dans le développement de Subversion (nombreux contributeurs, notamment Hyrum Wright, release manager du projet depuis 2008 et aussi « Director of Open Source » chez Wandisco). Ces deux entreprises vendent des produits et services articulés autour de Subversion.
Dans une dépêche plutôt hostile et mensongère publiée fin 2010, dans laquelle il dénonce la lenteur du projet en des termes assez crûs (« certains contributeurs sans scrupules n'hésitent pas à faire des changements triviaux dans de larges fichiers, juste pour avoir de meilleures statistiques »), Dave Richards (CEO de Wandisco) annonce que son entreprise se résigne à faire le boulot nécessaire pour implémenter les fonctionnalités attendues depuis trop longtemps par les utilisateurs (notamment, améliorer le système de fusion). « Enough is enough », écrit-il. Sous-entendu : Collabnet qui portait le projet jusque-là n'était pas à l'écoute des utilisateurs. Coup marketing évident.
Cette dépêche a suscité de nombreuses réactions de la part des acteurs mis en cause, réactions allant de la déception à la moquerie : c'est Mark Pippard qui fait remarquer que WANdisco a déjà fait le coup de la dépêche de presse il y a un an, pour annoncer de nouveaux super-développements autour de Subversion : SubversionJ et Obliterate, deux développements qui n'ont jamais vraiment commencé.
Les relations sont maintenant tendues, et Wandisco ne semble pas vouloir assumer un fork, puisque l'entreprise essaie maintenant de se rabibocher ouvertement avec la fondation Apache (dans une nouvelle dépêche publiée aujourd'hui, ils se réjouissent d'être devenus sponsor officiel de la fondation).
Il sera donc intéressant de voir comment la situation évolue, notamment en ce qui concerne la sortie prochaine de Subversion 1.7, toujours prévue pour début 2011 et impliquant des développeurs issus de toutes les parties concernées. Cette nouvelle version doit apporter à Subversion des améliorations au niveau de la couche HTTP et de la gestion de la copie de travail, premiers pas vers des fonctionnalités distribuées à la Git.
Aller plus loin
- Premier post de Dave Richards (31 clics)
- Réponse de Mark Phippard (18 clics)
- La fondation Apache tente de rétablir la vérité (7 clics)
- We are now a sponsor of Apache! (5 clics)
- La roadmap de Subversion (11 clics)
# donc si je comprend bien
Posté par briaeros007 . Évalué à 10.
On va les faires".
Au milieu il y a une pique ou deux, il se fait mousser une ou deux fois, ok.
Mais honnêtement ça n'a rien de particulièrement "fort", surtout quand on a déjà vu la prose de linus.
Et derrière on a une entreprise et une fondation qui dit "non mais comment osez vous coder sur un projet open source.
De toute façon vous êtes rien" (je cite :
No one knows or cares who WANDisco is;If you are so desperate for attentionBref, sans vouloir être vexant, niveau com je préfère quand même wandisco.
Quand on joue les vierges effarouché, il en faut pas en même temps avoir exactement le même comportement que ce qu'on reproche (et NON le coût du "c'est l'autre qui a commencé" ca marche en primaire, mais pas pour des gens un minimum évolué).
Bref, pour moi un non évenement, qui c'est transformé en affaire de part la susceptibilité de part et d'autres (oui il y a des cons qui s'amuse a jouer au con (commits inutiles, communiqué de presse avec des piques inutiles, lettre ouvertes pleine de sarcasme inutiles).
[^] # Re: donc si je comprend bien
Posté par patrick_g (site web personnel) . Évalué à 10.
Hop un petit GOTO vendredi !
[^] # Re: donc si je comprend bien
Posté par Dorian . Évalué à 10.
Mouhaha, dédicace à tout ceux qui critiquent Git pour sa décentralisation.
(Ici git la tombe de SVN)
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
# c'est pas franchement grave
Posté par Albert_ . Évalué à 7.
Ce genre de nouvelle aurait pu etre "inquietante" a l'epoque de CVS ou subversion mais bon aujourd'hui c'est plus amusant qu'autre chose...
Desole pour les fans de subversions mais bon le vents a tourne.
[^] # Re: c'est pas franchement grave
Posté par vlad59 (site web personnel) . Évalué à 1.
[^] # Re: c'est pas franchement grave
Posté par moules . Évalué à -4.
[^] # Re: c'est pas franchement grave
Posté par Hank Lords . Évalué à 4.
[^] # Re: c'est pas franchement grave
Posté par The Eraser . Évalué à 7.
[^] # Re: c'est pas franchement grave
Posté par DLFP est mort . Évalué à 2.
À la limite quelques fonctions sympa comme stash ou une queue de commits, histoire de le rendre sa fin de vie moins douloureuse.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: c'est pas franchement grave
Posté par calandoa . Évalué à 2.
Malgré l'enthousiasme autour de git, je n'ai pourtant pas l'impression que git pourrait convenir dans notre cas : en gros le repository principal contient une série de répertoires, chacun étant un module, par ex a, b, c... et ce repository a été branché un tas de fois, par ex 1, 2, 3... maintenant, les nouvelles branches utilisent certains modules des autres branches : par ex la branche 26 va contenir a_26, b_15, c_20, d_26, e_13. Le tout est bien sûr géré par ces surcouches, des scripts qui vont s'occuper de faire des check outs de chaque module depuis la branche indiqué dans un fichier de config.
Bon, le fait est que cvs et svn ne sont eux même pas capable de gérer ça tout seul, mais j'ai l'impression qu'ils conviennent mieux que git qui n'est pas capable (enfin je crois) de gérer seulement un sous répertoire extrait d'une branche.
[^] # Re: c'est pas franchement grave
Posté par DLFP est mort . Évalué à 2.
La solution peut être de faire un repo git par dossier, et ensuite avoir un repo maître qui utilise les submodules. Dans tous les cas tu vas avoir tout un tas de scripts autour…
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: c'est pas franchement grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: c'est pas franchement grave
Posté par calandoa . Évalué à 8.
- les qqs fichiers .c de 50.000 lignes (au milieu de centaines d'autres), gérés manuellement bien sûr...
- certaines struct de plus d'un millier de lignes
- les historiques cvs tellement gros que 90% des outils plantent. Avec une version patchée de cvsgraph, j'ai quand même réussi à générer un png de 20.000x30.000 pixels
- les makefiles imbriqués dans tous les sens, en général une dizaine d'appel des uns aux autres suite à un make, (et rien à voir avec un makefile par répertoire)
- l'enfer des #ifdef dans tous les sens
- le code « romifié », çad que une grosse partie du code compilé est déjà dans la ROM des produits et est donc supprimée lors du link... va comprendre pourquoi tes modifs ne changent rien...
- des développeurs répartis sur toute la planète, des mailing lists qui croulent sous les rapports d'outils de build et de tests automatisés, et sur les annonces de tag (« je vais taguer telle branche, suspendez les commits »)
- et le petit détail qui tue sur lequel je suis tombé il y a qq jours : il y un connard qui a rentré comme commentaire de commit un message sur une dizaine de ligne reprenant le format exact de la sortie de cvs log... bluffant... après des heures de debug sur un script qui plantait, j'ai encore mis 10mn à identifier dans le log le début et la fin exacts du commentaire foireux.
[^] # Re: c'est pas franchement grave
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: c'est pas franchement grave
Posté par moules . Évalué à 4.
[^] # Re: c'est pas franchement grave
Posté par calandoa . Évalué à 5.
[^] # Re: c'est pas franchement grave
Posté par El Titi . Évalué à 3.
i.e que tu définis des articles de configuration qui ne sont pas de simples fichiers et qui obéissent à leur propre cycle de vie.
C'est le pendant coté GCL de l'architecture à base de composants
http://en.wikipedia.org/wiki/Component-based_software_engine(...)
Ton application est un simple assemblage de plusieurs versions de composants.
Un composant peut être réutilisable dans plusieurs projets différents, modifiable ou non dans le projet.
On est soit fournisseur, soit consommateur du composant.
Si c'est un composant binaire et que tu es consumer et que tu n'a pas besoin de faire évoluer les sources tu t'en sors avec des outils comme Maven et un VCS est superflu sinon c'est utile.
UCM et Clearcase gère ça pas trop mal.
SVN le fait grâce au svn copy ("cheap copies") et aux svn:externals
Avec mercurial il faut utiliser le submodules et il doit y avoir un équivalent sous Git.
http://stackoverflow.com/questions/2479274/using-mercurial-i(...)
[^] # Re: c'est pas franchement grave
Posté par gaaaaaAab . Évalué à 6.
Ici, on utilise toujours CVS d'ailleurs ...
[^] # Re: c'est pas franchement grave
Posté par ploum (site web personnel, Mastodon) . Évalué à 6.
Je connais pas mal de boîte où les "geeks" de service font de la promotion de Subversion comme l'outil moderne à la mode. Les conservateurs eux, sont plutôt Clearcase ou envoi de zip sur des FTP (oui oui, je suis sûr que le code de votre micro-onde/lave-vaisselle/voiture est développé comme ça).
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: c'est pas franchement grave
Posté par gaaaaaAab . Évalué à 5.
Mais dans mon premier boulot, j'avais mis en place un CVS pour remplacer la méthode cpold, qui offrait pourtant déjà la possibilité de remonter jusqu'à la version N-1 !! \o/
Bon, je suis un peu médisant, cpold était couplé à rccs ...
[^] # Re: c'est pas franchement grave
Posté par flagos . Évalué à 2.
Je ne connais pas du tout Clearcase, avez vous des elements de comparaison avec git ?
[^] # Re: c'est pas franchement grave
Posté par Pierre . Évalué à 1.
C'est plus compliqué que de le faire a des gens qui n'ont jamais fait de VCS.
Le plus dur est leur faire comprendre qu'il ne faut surtout pas faire d'analogie, ou essayer de retrouver des methodes de travail.
Ca n'a rien a voir. Point. Le workflow est complètement different.
cc travaille sur des fichiers (et des repertoires), git travaille sur un repo complet et coherent.
La notion de branche n'a rien a voir.
"checkout" a une sémantique complètement differente.
J'en passe...
[^] # Re: c'est pas franchement grave
Posté par El Titi . Évalué à 6.
Les habitués de CC sont plus difficiles à convaincre simplement parce qu'ils savent maitriser un VCS digne de ce nom qui sait gérer des branches efficacement et merger sans se tromper. Ceux qui ont toujours défendu CVS et SVN face au vilain proprio m'ont toujours fait marrer:
- Les vues dynamiques qui te permettent de browser le dépôt sans le cloner avant
- possibilité de bosser en lock pessimiste ou optimiste
- les clones existent depuis toujours avec en plus des branches qui ne sont pas propres à un user mais dont la maitrise peut être transférée
- les tags sont des objets à part entière pas comme SVN
- les attributs qui font encore la pige aux properties de SVN
- le rename tracking
- les triggers sur plein de commandes qui permettent de le customiser à sa sauce
Bref il tient encore bien la comparaison avec Git et Hg
Mais aujourd'hui il a 20 ans, le monde à évolué et il montre ses lacunes
- privilèges d'accès lié à l'OS
- protocole verbeux
- plage de port au lieu d'un seul
....
C'est un outil adapté au travail en LAN mais beaucoup moins au travail distant
[^] # Re: c'est pas franchement grave
Posté par Pierre . Évalué à 2.
Pas d'accord les VCS ont chacun un ensemble de fonctionalités qui orientent le workflow de manière vraiment importante. Si on veut être efficace, il faut aller dans le sens du workflow de l'outil.
Cela dis, je ne critique pas du tout le workflow de cc. Les idées qu'il y a dedans sont vraiment bien.
C'est juste que c'est mega lent, qu'il faut une équipe complète d'admin pour gérer un serveur pour 50 personnes.
Maintenant on a un gitorious qui a pris une semaine a installer (sans être spécialiste IT ni connaitre RoR avant), et a configurer pour nos besoin, et ca tourne tout seul.
[^] # Re: c'est pas franchement grave
Posté par El Titi . Évalué à 4.
CC permet justement de s'adapter à quasiment tous les workflows de projet et est customisable à partir de sa version de base.
Tu peux utiliser un workflow prêt à l'emploi avec la surcouche UCM.
Avec Git, c'est la même chose, simplement il faut s'investir pour définir clairement son besoin.
Les spécificité des outils ne doivent intervenir qu'à la marge sinon c'est que l'outil n'est pas adapté.
Ton exemple montre juste que tu veux un truc prêt à l'emploi auquel cas il faut effectivement changer ses habitudes.
Si tu as affaire à un rejet il faut peut-être prendre le temps de comprendre le besoin et mettre en oeuvre une vraie conduite du changement. La Rache a ses limites (mais peut-être que vous n'êtes pas nombreux)
C'est juste que c'est mega lent, qu'il faut une équipe complète d'admin pour gérer un serveur pour 50 personnes.
Pour la lenteur je te donne pas tort (le poids de l'âge).
Pour l'équipe d'admin, c'est encore un pb d'organisation.
Chez nous une équipe de 3 admin gère une DSI de plusieurs centaines de développeurs en ayant proposé un worklow et un toolset associé.
Après on nomme un responsable GCL (un dev senior) par projet qui s'occupe de mettre en oeuvre le workflow et de coacher lorsque les devs de base en ont besoin. L'admin au sens propre: coté client et serveur + méthode + support ne monopolise que 3 ressources.
[^] # Re: c'est pas franchement grave
Posté par El Titi . Évalué à 9.
* ne pas attendre 15s avant de pouvoir commencer à éditer un fichier
* ne pas râler après Gaston qui est parti en vacances sans relâcher ses fichiers
* ne pas attendre 10 mns pour se créer une vue et une config spec et commencer à bosser sur un patch urgent
* ne pas se retrouver avec la moitié de son changeset commité et casser le build (transaction atomique), quoique UCM avec un projet multistream (rebase/deliver) revient exactement au même que Git avec push mais alors quelles emmerdes par ailleurs (gestion des baselines foiireuse, ...)
* poser un tag en 5 secondes
* branches locales
* Pouvoir bosser et commiter à la maison sans pb
* S'interfacer avec tous les outils open source ou cheaps de la planète et ne pas se limiter à Clearquest ou Jazz (integration JIRA=>Fisheye +Tasktop pas terrible, Hudson= galère, ..)
* suivre l'historique de ton projet et pas seulement au niveau du fichier (UCM pallie par contre)
* avoir un DSI heureux de ne pas gaspiller des dizaine de Keuros par an et acheter du super matos à la place
* Pouvoir bosser avec une boite exterieure sans que ce soit insurmontable (avec CC multisite obligatoire, ceux qui auront tenté de convaincre de mettre en place du multisite comprendront, .... ouvrir une plage de ports au lieu d'un seul port, qui paye les licences ? gestion du mastership, alignement des version des serveurs, ...)
* git bisset
* star merge
...
Par contre tu auras du mal à convaincre ceux qui aime la securité du reserved checkout (usage basique pour quelques scripts), de convaincre que le merge git de base est mieux que le merge 3 ways de CC
(le rename tracking se fait sur le hash et tente de deviner quand un fichier est renommé ce qui ne gère pas certains cas).
Y'en aurait encore à dire, je ferai un petit journal un de ces 4
[^] # Re: c'est pas franchement grave
Posté par Nimlar . Évalué à 0.
Oui oui un journal !
passage CC UCM vers git ici aussi
[^] # Re: c'est pas franchement grave
Posté par tyoup . Évalué à 5.
les centrales nucléaires aussi ! mets un scm entre les mains de mes collègues et tu verras que pour eux c'est une usine à gaz destinée à les rentre contreproductifs. un jour un a décidé de demander un "patch" à son éditeur, il n'a pas su quoi faire avec le fichier que celui-ci a envoyé.
[^] # Re: c'est pas franchement grave
Posté par Christophe Fergeau . Évalué à 2.
Les entreprises sont à peu près réceptives à subversion ou l'utilisent déjà, et ça permet de faire du git-svn dans son coin ;)
[^] # Re: c'est pas franchement grave
Posté par Victor STINNER (site web personnel) . Évalué à 2.
http://wiki.freebsd.org/VersionControl
Tiens, il semble d'ailleurs que l'OS plus libre que libre (FreeBSD) utilise d'ailleurs un logiciel proprio en plus pour gérer son code : Perforce.
[^] # Re: c'est pas franchement grave
Posté par djano . Évalué à 2.
Et oui: comment réécrire un concept dépassé. M'enfin bon, ils disent que ça répond a leur besoin, tant mieux pour eux.
Le problème c'est que d'autres personnes les croient et continue a utiliser CVS grâce a eux (a cause d'eux?).
Tiens, il semble d'ailleurs que l'OS plus libre que libre (FreeBSD) utilise d'ailleurs un logiciel proprio en plus pour gérer son code : Perforce.
Du moment que tout le monde n'est pas forcé de l'utiliser (puisque c'est en plus), alors ça ira.
Quand Linux utilisait exclusivement BitKeeper, c'était quand même plus gênant.
[^] # Re: c'est pas franchement grave
Posté par Patrick Lamaizière (site web personnel) . Évalué à 2.
FreeBSD utilise SVN depuis quelque temps déjà (deux ans ?)
D'ailleurs, CVS est aussi nécessaire sur le poste client pour utiliser les ports FreeBSD non ?
Le SVN est "mappé" vers CVS pour pouvoir utiliser les outils existants (en attendant de les remplacer). En général on utilise csup/cvsup pour récupérer les sources ou les ports.
Tiens, il semble d'ailleurs que l'OS plus libre que libre (FreeBSD) utilise d'ailleurs un logiciel proprio en plus pour gérer son code : Perforce.
Perforce contient seulement des branches expérimentales. Par exemple c'est là que sont stockés les Googles Summer of Code. Je ne sais pas pourquoi ils avaient choisi perforce, mais c'était déjà en place bien avant le SVN.
les pixels au peuple !
[^] # Re: c'est pas franchement grave
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 4.
# merge et rename tracking
Posté par El Titi . Évalué à 7.
annonce que son entreprise se résigne à faire le boulot nécessaire pour implémenter les fonctionnalités attendues depuis trop longtemps par les utilisateurs (notamment, améliorer le système de fusion)
http://subversion.apache.org/roadmap.html
Q1 2011 Branch 1.7.x 1.7.0 feature-complete
...
Q1 2012 Release 1.8.0 repository-dictated config; tree conflicts improvements; rename tracking;
rename tracking issue
=>
Sous Apache
http://subversion.tigris.org/issues/show_bug.cgi?id=3631
=> rename issue tracking ala SVN =>
Sous Tigris
http://subversion.tigris.org/issues/show_bug.cgi?id=898
Opened: Wed Sep 11 01:42:00 -0800 2002
...
"Absolutely must" ? This sounds like a feature which can be postponed
until after 1.0.
...
------- Additional comments from Peter N. Lundblad Fri Sep 23 04:33:46 -0800 2005 -------
Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
renames branch, it won't be merged before 1.3.
...
------- Additional comments from Peter N. Lundblad Tue May 2 01:14:02 -0800 2006 -------
The 1.4 branching point is approaching and this is not happening before that,
so move into 1.5-consider.
...
------- Additional comments from Erik Huelsmann Wed Apr 4 08:50:16 -0800 2007 -------
With resources fully concentrated on Merge Tracking, I don't think having this
in 1.5 is viable. Moving to 1.6-consider.
....
------- Additional comments from Hyrum K. Wright Tue Mar 10 06:45:10 -0800 2009 -------
Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
move to 1.8-consider.
and now ? reported à la 1.?.? nom de code "Saint Glin Glin"
rename tracking kezako ?
1- créer un fichier foo.c sur le tronc et commiter
2- brancher
3- renommer foo.c en baz.c dans la branche.et commiter
4- editer foo.c dans trunk et merger dans la branche
....
Tadaaaa
compute ~~~~ SVN,~~~~ Failed ~~~~Git~~~~ Success ~~~~ Hg ~~~~ Success~~~~
Enjoy !!!!
Imaginez la joie de ceux qui se lancent dans un refactoring sous eclipse en renommant des classes ou des packages en utilisant plusieurs branches,(obligé de le rélancer dans tous les projets) vous comprendrez pourquoi l'intégration continue a de beaux jours devant elle avec un outil qui est incapable de merger correctement.
# Belle évolution
Posté par vieuxshell (site web personnel) . Évalué à 6.
Il y a 10 ans le troll de base concernait les éditeurs de texte, les environnements de bureau.
Avec la maturité du lectorat, emacs et gnome ont gagnés et le troll à la mode survient sur les outils de dev.
Dans 10 ans, quand git et hudson auront gagnés, trollera-t'on sur CMMi vs Scrum ?
[^] # Re: Belle évolution
Posté par Moonz . Évalué à 10.
(oui, c’est un troll : il faut bien reconnaître qu’au niveau éditeur de texte, emacs, c’est pas encore ça)
[^] # Re: Belle évolution
Posté par lolop (site web personnel) . Évalué à 3.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Belle évolution
Posté par daeldir . Évalué à 1.
http://www.framasoft.net/article1000.html#comments64090
Commentaire qui mène sur ces pages :
http://emarsden.chez.com/downloads/ (où se trouve le script)
http://www.ietf.org/rfc/rfc2324.txt (le protocole implémenté par le script)
Après, je n'ai pas testé : je n'aime pas le café et j'utilise vim.
[^] # Re: Belle évolution
Posté par zebra3 . Évalué à 3.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Belle évolution
Posté par Bruno Michel (site web personnel) . Évalué à 7.
[^] # Re: Belle évolution
Posté par nicolas . Évalué à 4.
Le problème des VCS, c’est qu’on finit tous par tomber d’accord sur git.
[^] # Re: Belle évolution
Posté par bat13 . Évalué à 2.
[^] # Re: Belle évolution
Posté par windu.2b . Évalué à 3.
La Rache a déjà gagné...
# Wandisco ne semble pas vouloir assumer un fork
Posté par flagos . Évalué à 10.
[^] # Re: Wandisco ne semble pas vouloir assumer un fork
Posté par vrm (site web personnel) . Évalué à 2.
[^] # Re: Wandisco ne semble pas voulo
Posté par wandisco . Évalué à 0.
Not true. Being good corporate citizens, WANdisco are the first Subversion corporate sponsor to adhere to the trademark use guidelines. We are doing this voluntarily. It would be nice if other referred to Subversion as "Apache Subversion" in their marketing.
We are making great strides on the Apache Subversion project. For instance Philip Martin, one of our Subversion commiters reported and fixed the security release for Subversion 1.6.16. We are also updating progress on our Blogs for the promised work around branching and merging.
I am very pleased that some of you have correctly spotted the FUD / misinformation from a certain company we compete with...
# FFmpeg...
Posté par Francois Revol (site web personnel) . Évalué à 4.
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/123868
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/123963
http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/125161
Avec un beau fork à la clé.
[^] # Re: FFmpeg...
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: FFmpeg...
Posté par lolop (site web personnel) . Évalué à 2.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: FFmpeg...
Posté par Victor STINNER (site web personnel) . Évalué à 2.
[^] # Re: FFmpeg...
Posté par Zenitram (site web personnel) . Évalué à 3.
[^] # Re: FFmpeg...
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: FFmpeg...
Posté par j_kerviel . Évalué à 5.
# J’y crois pas
Posté par Sylvain Sauvage . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.