wilk a écrit 1159 commentaires

Le plus simple c'est encore de faire tes petites bidouilles dans un clone à part, que tu merge dans ta branche principale quand c'est prêt à pusher. C'est la différence avec git où dans le même répertoire tu peux avoir plusieurs branches aussi distinctes que des clones.

rebase, tu l'as comme extension dans mercurial, ça permettra de "rebaser" tes bidouilles dans l'historique comme si ça avait été dans la même branche, plutôt que de faire des merges.
http://www.selenic.com/mercurial/wiki/RebaseProject

Tout dépend de ce que tu fait comme administration !

Par exemple j'utilise un petit programme python qui me génère des comptes mails. Ensuite, je lance l'interpréteur et je peux faire des choses du genre
m = mail.Mail("wilk", "domain.tld")
m.password = 'monpass'
m.write()

J'ai créé mon nouveau mail, c'est un 'objet' mail, très pratique... A utiliser soit dans l'interpréteur, soit bien sur dans un autre script. Si je veux envoyer un mail aux utilisateurs de tel domain, for mail in get_mails('domain.tld'): sendmail(blalabla, mail.email)...

La même chose pour ma conf apache, ftp etc. J'ai un objet site, site.documentroot=..., site.mod_wsgi=...

Ce n'est pas non plus pour autant une usine à gaz avec une interface graphique etc, ça reste du script d'admin.

On la retrouve où cette date ?

Dans la vraie vie comme tu dis, plus les données sont importantes, financièrement parlant, plus le critère de choix devient financier également et non plus technique. Bref, c'est l'assureur qui choisit et non le directeur technique.

Une traduction est en cours, si vous voulez nous donner un coup de main, c'est par là :
http://www.selenic.com/mercurial/wiki/index.cgi/TranslatingM(...)

J'ai également pris ma décision en lisant ce post :
http://article.gmane.org/gmane.comp.version-control.mercuria(...)

Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".

Il n'y a quand même pas que ces raisons, tout le travail de brett a été pris en compte :
http://www.python.org/dev/peps/pep-0374/

En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.

Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.

Je suis passé de bazaar à mercurial il n'y a pas très longtemps, il me semble tout simplement que mercurial est ce que bazaar cherchait à devenir en vain... Simple et rapide, il suffit d'essayer.

Parce qu'il est tellement pratique que pour ce que je fait ça a fait mentir l'adage comme quoi on programme mieux dans le langage qu'on connait le mieux et avec celui qui est en théorie le plus adapté au besoin. Le tout qui se vérifie sur la durée au niveau de la maintenance.
Que demander de plus ?

Ce que je fait avec ? Des scripts d'admin, de graphisme, de gestion, en ligne ou pas, sous linux ou pas, pro ou pas.

Et pour le plaisir d'être plus proche du système, de mes goûts, par nostalgie, pour que ça tourne plus vite, je m'autorise de lui coller un peu de C.

La seule fois où j'ai perdu du temps avec Python c'est quand j'ai décidé de migrer mes applis en utf8/unicode au lieu d'attendre la v3...

Guido est en train d'écrire l'histoire de python :
http://python-history.blogspot.com

Quelle est le meilleur ordre ? greylist puis rbl ou l'inverse ?

Forcement, quand t'as appris Java t'étais débutant :)
C'est ça qui est génial, je peux rester débutant tout en assurant mon job grâce au Python !
Je reviens sur mon paradoxe, autant on trouve pléthore de raisons pour obliger les développeurs à faire du java, autant tous ceux qui utilisent python l'on fait par choix. Curieux non ?
Bon j'arrête sinon je vais être obligé de raconter ma vie ;-)

Euh, même si tu divises le nombre de lignes par 2, je vois toujours pas le rapport, pour retrouver la méthode bidule, t'iras toujours la chercher dans la classe machin dans le fichier truc dans le dossier pouet.
Si tu n'arrives pas à comprendre qu'un code plus court, plus concis et plus clair aide à s'y retrouver, je vois pas quoi rajouter... Mon argument ne tien peut-être pas a tes yeux deux minutes, mais ça fait quelques années que je l'apprécie au quotidien :-)

Moi je mets ma main à couper que dans 10 ans il va être super balaise de trouver un mec suffisament compétent pour intervenir rapidement sur ce genre d'appli,
J'ai du mettre quelques mois pour apprendre à sortir quelque chose de cohérent en java, en python ça m'a pris quelques jours. Je ne vois pas pourquoi dans 10 ans on aurait du mal à former quelqu'un dans un langage aussi simple et facile d'accès et qui ne bouge quasiment pas malgré ce qu'on peut lire ici.

un décideur qui a un ingénieur dubitatif devant lui, il prend peur et va se rassurer chez Sun MS ou autre IBM qui va lui offrir des garanties de support sur le long terme.
On en revient toujours au même. Quand on a un problème on s'imagine toujours que les autres les ont aussi, on regarde donc quels outils ils ont pour les résoudre au lieu de se demander s'ils ont eux aussi ces problèmes... L'IDE, le framework etc.
Un autre exemple tout bête. On dit souvent qu'il n'y a pas autant de livres sur python que sur java. Certe, mais autant en java j'ai du acheter d'énormes bouquins, en python aucun. Pourtant je fait exactement les mêmes choses avec... Y compris du multi-thread !

Un temps j'étais même fan de java, pourquoi j'aurai abandonné pour python ?
Soit parce que je suis compétent, et c'est donc un bon choix. Soit parce que je suis incompétent mais alors c'est encore mieux si un langage permet à un incompétent d'être encore plus productif ! ça devrait pourtant être l'inverse avec un langage qui rattrape autant d'erreurs ;-)

Tu m'expliques le rapport avec le langage ? L'organisation des sources et leur décomposition n'a pas grand chose à voir là dedans !

C'est tout simple, j'ai réécrit des programmes java en python, ils perdent statistiquement la moitié en lignes de code tout en devenant encore plus clairs et explicites (pas comme perl par ex). Ils perdent du volume d'une part parce que le langage est moins verbeux mais aussi par ce qu'il est moins contraignant.

Ah oué et demain t'as une faille de sécu et t'as 24h pour la corriger, tu fais quoi ? Tu réécris tout en Python ?
Je parle de grosses modifs. Si c'est pour corriger des bugs, quelque soit le langage comme je t'ai dit, ce n'est pas le plus gros problème, pas la peine de réécrire quoique ce soit.

C'est le problème de ton "je". Si t'es plus là ? faudra trouver quelqu'un qui maîtrise Python 2.x quand tout le monde sera à Python 5. Le mec s'apercevra peut être même que le bug est dans une lib Python que plus personne ne maintient parcque elle a été réécrite 3 fois...
Justement ce n'est pas le problème de mon "je" vu ça restera simple. L'avantage du KISS. Ce qui fait aussi que les soit disant problèmes d'incompatibilités entre les versions de python sont assez insignifiantes. Et de toutes façon, je me répète, l'environnement change beaucoup plus vite et oblige à beaucoup plus d'adaptations que les contraintes du langage.
Tu te focalises sur LE bug de l'application qui n'a pas évolué depuis 10ans et que tu n'aurais peut-être pas eu grace à la compilation...

Quand on est habitué, un code java est tout à fait lisible.

Encore faut-il retrouver le dit code ! J'ai encore quelques applis en java que je n'ai pas encore réécrite en python. Je passe mon temps à chercher où ce passe quoi ou à quoi pouvait bien servir tel autre code !
La encore Ploum a mis juste, on sent le vécu, le code était-il du M, du V ou du C !

Allez, je vais quand même avouer une chose, j'ai énormément appris quand j'ai fait du Java, à me structurer, à prévoir les failles etc. C'est un très bon langage théorique je dirai.

Franchement quand on fait de la maintenance, pour moi la priorité c'est d'assurer la non-régression, et tout les outils/méthodes qui peuvent m'offrir un certain niveau de sécurité sont le bienvenu. Bien plus que les backups ou la journalisation qui sont des problématiques totalement différentes de la maintenance. Ca c'est une problématique d'exploitation/infrastructure qui est globalement indépendance de ton langage de programmation.

La maintenance au niveau bug sur un programme qui tourne depuis 10 ans, normalement elle est quasiment inexistante... C'est d'ailleurs, pour ça, qu'on n'a plus les programmeurs qui vont avec. J'ai des applis qui ont une quinzaine d'années, en access et windev qui tournent comme des horloges, personne n'osera dire que c'est grâce au langage ! Par contre si je dois faire des grosses modifications, j'aurai plus vite fait de les réécrire en python que d'essayer d'aller voir si à l'époque j'écrivais du code maintenable ! Et la ce qui est important c'est d'avoir prévu des exports de données tout simplement.

Le piège, que Ploum a encore très justement mis en avant, est justement de penser que les problèmes d'exploitations sont différents des problèmes de programmation.
Dans 10 ans qu'est-ce qui m'empêchera de retrouver un environnement exactement identique à celui d'aujourd'hui ? Je n'ai besoin que de vim, python et deux ou trois librairies d'une taille ridicule. Grâce à la surveillance de Guido (de garder une implémentation simple) je suis même assuré de pouvoir corriger moi-même les éventuels bugs que je pourrai trouver dans le langage lui-même ou une des bibliothèques ! C'est là que ce jouera toute la différence dans le temps.

Ah ces SSII, qu'est ce qu'elles attendent pour coder en Python ? Qui veut coder une application qui dans 10 ans sera inmaintenable parcque Python 5 aura cassé 2 fois la compatibilité et qu'on trouvera plus un couillon qui sait faire du Python 2.6 ?

Si la maintenance d'un programme ne dépendait que de la compatibilité ascendante du langage ce serait merveilleux !!! Mais c'est déjà bien d'amener la discussion sur la maintenance, bien plus importante que la correction de bugs.

Déjà ça dépend de bien d'autres facteurs comme l'environnement système, les bibliothèques utilisées, les bases de données etc. Mais là tu vas nous expliquer, avec raison d'ailleurs, comment java résout le problème beaucoup mieux que python. Mais surtout ça dépend de la clarté du code et de la simplicité de son architecture. Et c'est là qu'entre en jeu les avantages des langages comme python avec un code beaucoup plus concis et beaucoup plus explicite. Souviens toi toujours de la règle qui dit qu'on passe beaucoup plus de temps à faire évoluer un code qu'à l'écrire ou à maintenir l'existant. Il ne faut pas se focaliser sur le bug de syntaxe, ce genre de bug, mis à part pour les départs de navette spatiale, généralement ils ne sont pas très gênant et se réparent dans tous les cas très rapidement. Et quand bien même, ce n'est ni par la compilation ni par les tests unitaires qu'on s'en protège, mais plutôt par des solutions de backup et de journalisation. Par contre le bug du client qui au dernier moment dit que ce n'est pas du tout ça qu'il voyait, celui la il est très fréquent et beaucoup plus difficile à déceler à la compilation ou au checker !

C'est un projet personnel ou y en a d'autres sur le coup ?

Les contraintes de ces grosses boites, c'est pas que les cravates, c'est aussi le nombre de développeurs qui y travaillent pour gagner leur croute. L'intérêt de java est de pouvoir bien cadrer tout ce petit monde quitte a sacrifier les ressources machines. Par contre pour des projets à taille plus humaine et a ressources restreintes où on a besoin de l'innovation et de la motivation des développeurs c'est plutôt un frein. Ce n'est pas pour rien non plus que ces même grosses boites dont tu parles utilisent aussi d'autres langages.

Vu la vitrine que représente linuxfr ce serait intéressant de faire du choix du framework et du langage une sorte de défi. On prendrait une partie critique du site à faire et on bencherait autant la vitesse de sortie que le nombre de ligne de code.

>>> from string import Template
>>> print Template('bonjour $nom $prenom').substitute(nom='archi', prenom='bald')
bonjour archi bald

J'ai compris comme toi, l'intérêt de perf et de taille c'est quand le format binaire est utilisé
http://code.google.com/apis/protocolbuffers/docs/encoding.ht(...)
Ce n'est du coup plus du tout lisible...
Ce que je comprend c'est en gros qu'on a là un format binaire pour échanger des données entre c++, java et python.
Bof aussi donc...

Je n'ai pas tellement suivit l'évolution de svn, mais j'aimerai préciser que l'intérêt des "décentralisé" n'est pas que d'être décentralisés. Du reste ils peuvent également être utilisé en mode centralisé ! (l'inverse aussi d'ailleurs).
Personnellement, travaillant la majorité du temps seul et voyageant plutôt à vélo qu'en avion, je me décentralise rarement. Pourtant je profite énormément de bazaar. Pour ce que j'avais du mal a faire avec cvs :
Je crée pleins de branches (c'est rapide et léger).
Une par fonctionalité, bug.
Une par client (qui n'utilisent pas tous la même version).
Ce que j'aime bien avec bazaar c'est qu'après une fusion je garde dans les logs une trace visible (indenté) de quoi a été fait pour qui.
Ca donne quelque chose du genre (qui il me semble ne rend pas comme ça avec hg ou git)

revno : 1234
date ...
message :
merge bs
revno : xxx
message :
entete en couleur pour bs
revno : yyy
message :
tri demandé par machin de chez bs

revno: 1233
date ...
message :

merge bug trucmuch
revno : xxx
message :
finalisation de la correction
revno : xxx
message :
1ere tentative de correction


etc. Donc chaque étape regroupant plusieurs commits dans une branche à part reste bien visible. Une étape peut également montrer une autre étape s'il y a un merge entre deux branches (indenté d'avantage etc.).

Ensuite, si je souhaite montrer le code à un collègue il y a bien sur tout un tas de possibilité de push pull & co, automatique ou non...

Sur l'interface lourde vs légère, on peut aussi prendre le problème à l'envers et chercher comment le résoudre pour ne plus avoir besoin d'une interface trop riche. On profite par exemple d'une interface web pour décentraliser et ainsi alléger les taches de chacun. C'est ce qu'on me demande en très grande majorité.

Mais d'après ce que j'ai compris vous avez prévu les deux solutions.

A propos de la communauté postgresql, quelle est la mailing liste (ou forum) francophone la plus active ? Je suis inscrit par sur http://www.postgresql.org/mailpref/pgsql-fr-generale mais je la trouve vraiment peu fréquentée...

De plus en plus souvent je constate qu'en entreprise il y a beaucoup plus de chance d'avoir un pépin local (à cause des configs locales qui sont de plus en plus complexes et qui changent tout le temps) qu'un pépin réseau (externe).
De même pour la confidentialité, il y a beaucoup plus de problème de fuites au sein même de l'entreprise que sur un serveur en ligne.
Inutile de parler des backups !