djano a écrit 1147 commentaires

Est ce que vous connaissez un outil qui permette la chose suivante:
- Dans trunk (ou main), j'ai un répertoire "dir"
- Je crée la branche A a partir de trunk
- Dans trunk, je renomme le répertoire "dir" en "rep"
- Dans la branche A, j'ajoute un fichier "file" au répertoire "dir". Le numéro de révision est 10378.
- Quand je merge la révision 10378 de la branche A vers trunk, voici ce que je veux obtenir: le fichier "file" est ajouté au répertoire "rep" de trunk.


Aucun des VCS que j'ai testé ne permet ca automatiquement:
- SVN refuse cela et me repond "tree conflict"
- Git l'accepte, mais me crée un fichier "file" dans le répertoire "dir" sur trunk (alors que je voulais ce fichier dans le répertoire "rep")
- D'après ce que j'ai lu sur Mercurial, qui ne se rappelle pas des répertoires, je ne pense pas que ca marcherait. Mais je ne sais pas ce que ca fait.
- Avez vous d'autres idées d'outils?

Perso je prefere git (il ne se traine pas la passif de svn et donc de cvs...).
J'ai failli te plusser, mais quand j'ai lu cette phrase que j'interprète comme "git ne se traîne pas le passif de SVN, alors que hg se le traine", et bien j'ai eu très envie de t'inutiler car c'est complétement faux. J'ai réussit a résister malgré tout.
Hg, tout comme Git, est basé sur des concepts totalement différents de CVS et SVN et ne se traîne aucun passif.

Par ailleurs, SVN ne traîne aucun passif de CVS. Ils ont juste choisit de faire un VCS centralisé (comme CVS), mais ils ont fait table rase de tout le reste et n'hésitent pas a remettre en cause des choix faits dans les versions précédentes de SVN. Maintenant le modèle centralise ne correspond peut être pas a ton workflow ou a celui du libre, mais ca correspond encore a celui de beaucoup de personnes.

Oui, quel est le rapport?

Un truc qui manque a SVN, c'est quand même des bons outils de merging & branching. Parce que lorsque tu travailles sur des branches, c'est quand même la grosse merde pour faire marcher tout ca correctement (même si ca s'est amélioré depuis un moment).
J'ai toujours pas compris le besoin de faire un truc a la Svnmerge.py avec des méta données qui viennent te pourrir tous les fichiers avec des métadonnées alors que le fichier lui même n'a jamais changé. C'est tout simplement incompréhensible.

L'avantage que je vois a Git par rapport a Mercurial est l'intégration avec SVN. Le seul probleme est que je l'ai utilisé sur notre projet mastondontesque sur windows (bouh! Heureusement cygwin est la!) et perl s'est lamentablement vautré comme une loutre bourrée un soir de Saint Sylvestre. Sacrées loutres!

avec des mainteneurs qui n'utilisent pas le systeme et menacent de tout laisser tomber des que les gens ne sont pas d'accord avec eux - genre extremiste du LL, ironique quand tu fais du dev pour windows).
LOL. Certaines personnes sont marrantes quand même. Je leur suis tout de même reconnaissant pour le boulot réalisé :)

comme pour toutes les distributions linux,
Oui! Car il y a 120 000+ distributions, et encore, je sous estime le nombre.

comme pour kde<=>gnome
Oui, si tu rajoutes a cela XFCE, Enlightenment, Etoilé, ...
Quels autres environnement de bureau propose aussi tout un tas d'applications qui vont avec?

comme vim<=>emacs...
Oui si tu rajoutes a cela gedit, kate, SciTE, Notepad++, notepad2, nedit, nano, jedit, et j'en oublie.


Autant je "connais" des buts différents e irréconciliable a chaque environnement de bureaux, autant je connais la raison de l'existence de la plupart des éditeurs de textes (mais pas tous), autant les distributions linux se multiplie comme des lapins tellement c'est facile de se baser sur une distro principale qui a fait le boulot ingrat (mais la je suis plus dubitatif sur l'existence de nombre d'entre elles), autant je ne connais pas la raison qui fait que toutes ces syntaxes de markup existe, d'où mon incompréhension.

Infidèle!
Tu seras banni de l'Église d'Emacs par Saint Ignucius lui même!
http://stallman.org/saintignucius.jpg

Euh tu va un peu vite en besogne pour SVN. Je ne serais pas celui qui le défend bec et ongle, mais il permet des choses que git et mercurial ne permettent pas. Voir pour un retour d'expérience:
http://live.gnome.org/GitMigration

Par exemple un sparse checkout: les traducteurs ouzbeks de logiciels GNOME doivent maintenant télécharger tous le logiciel au lieu de simplement faire un checkout sur le répertoire des traductions avec un debit internet famélique. Pareil pour ceux qui ne travaillent que sur le répertoire site/ pourquoi devraient ils prendre le code source aussi?

Lors d'un merge, si les heuristiques de Git ne marchent pas dans ton cas, alors pas de bol pour toi. Par exemple: nous avons réorganisé le code pour le rendre plus modulaire (déplacement de repertoires , de fichiers, etc.). Quand j'ai essaye Git pour faire un merge de fichiers ajoute a un ancien répertoire, Git me l'a recrée dans un répertoire qui n'existe plus dans la branche ou je fais le merge! Mercurial doit mieux gérer ce cas la je pense puisqu'il gère individuellement les fichiers. Par contre cette faculté de Git lui permet de se rappeler toutes les lignes de codes, même si le code a été déplacé dans un autre fichier.


Enfin, le plus gros argument, c'est que pour une grosse équipe de développement, passer de SVN a Git/Mercurial implique un grand changement dans la façon de travailler, parce que l'outil ne fait pas tout et que les humains sont plus essentiels que les outils. Si les gens sont plus a l'aise avec SVN parce que SVN est beaucoup plus simple a comprendre, alors peut être que les outils plus avancés ont manqué quelque chose? Un exemple a la con serait Google Wave qui devait rendre l'email, l'IM, les wikis et les forums obsolètes, pourtant toutes ces choses sont encore la et pas encore dépassées (J'avais prévenu que c'était un exemple a la con).


Bien sur je ne dénie pas les avantages qu'apporte Git et Mercurial, mais tout n'est pas rose non plus et SVN est encore la pour un bon bout de temps. Donc SVN n'est pas si dépassé ni même prêt de disparaître.

D'après ce que je connais sur git, tu as tout a fait raison.
par défaut git ignore tous les fichiers présents jusqu'à ce que tu fasse un git add avec leur nom.

Tu passes a cote de la joie:
- du versioning fichier par fichier,
- impossible de copier un fichier sans perdre l'historique.
- impossible de copier un répertoire,
- des commits non atomiques (coupure de courant au milieu d'un commit? pas de bol!)
- non possibilité de voir tout ce qui a été committé exactement ensemble, la vitesse pou les opérations basiques (diff des modifications dans ton wokspace avec la révision a laquelle il se trouve), etc. J'en passe et des meilleures.

Si tu veux vraiment voir ce que tu manques (ou que tu as 5 min a perdre), voici quelques liens:
- http://www.pushok.com/soft_svn_vscvs.php
- http://www.journaldunet.com/developpeur/tutoriel/out/060127-(...)
- https://secure.wikimedia.org/wikipedia/fr/wiki/Apache_Subver(...)

Non vraiment il ne faut pas regretter CVS et encore moins les outils qui existaient avant. Les gens qui décident d'utiliser encore SCCS, doivent être maso ou sacrément obtus.



Maintenant, SVN et git/mercurial/... ont des workflow différents et s'applique a des besoins/situations différentes. Je travaille avec SVN tous les jours et ca marche quand même pas mal. Parfois je me dis bien que tel gestionnaire de version X ou Y a telle fonctionnalité qui me serait bien utile dans une situation précise, mais c'est quand même assez rare. On arrive toujours a se débrouiller.

Oh j'ai bien conscience de ca, mais ce n'était pas mon propos.

Ce que je voulais dire c'est que 13+ langages de markup c'est quand même un peu trop. Je pense au temps/énergie/détermination passé par leurs auteurs respectif pour les créer et je pense a ce qu'il aurait été possible de faire de ce temps sur d'autres projets. J'ai pris OpenOffice.org ou LibreOffice, mais j'aurais pu parler de Firefox, KDE, Gnome, ou même GCC (!?!). Je sais bien que ces projets n'ont rien a voir avec un langage de markup, et que les développeur n'auraient peut être jamais contribué a ces logiciels libres que je cite (ou même a d'autres).

C'est juste que tous ces langages de markup me laissent un sentiment de réinvention de la roue, voie même un gâchis.

Bravo a toi Bruno, c'est un super boulot!

C'est aussi une super idée le concours de design, comme ca ca évitera trop de décollements rétiniens aux moules francophones ^_^

Et puis, comme un consensus est difficilement trouvable, un nouveau projet propose sa nouvelle syntaxe. C'est relativement humain comme comportement.
Je ne sais pas si c'est humain, mais en tout cas ca semble être plus facile d'écrire son propre système de markup que de contribuer a OpenOffice.org par exemple (ou LibreOffice selon ce qui vous plaît) .

c'est dommage, car comme par hasard, ils sont arrivés presque aux mêmes conclusions que ce qui avait été choisi initialement dans txt2tags.
J'imagine que tu parles de la syntaxe qui est proche?

Pour ma part je dois vraiment être jeune parce que pour moi un vieux gestionnaire de version c'est subversion et un jeune c'est git/mercurial.
En effet, pourtant j'ai pas encore la trentaine. SVN est top moumoute par rapport a CVS, mais git et mercurial sont radicalement différents, et jeunes comme tu dis. Ca se sent au niveau des outils gravitant autour et de l'intégration avec les IDE.

Ceux qui t'ont présenté CVS comme ancestral ont bien fait, ils t'ont bien appris.

Vous démontrez de manière absurde comment (si vous faites parti de l'organisation) le débat sera impossible dans votre association, et que j'avais raison sur ma prédiction. Merci :)

Michel a déjà dit qu'il n'en faisait pas partie. Je te cite:
PS lire est une qualité

Autant ton point de vue sur cette association est intéressant, autant ton agressivité te dessert. Relax.

Hum en effet, je suis passé trop vite sur le mot "source". Merci Zenitram de me l'avoir fait remarquer.

J'aimerais bien comprendre pourquoi il y a 13 syntaxes de ce type sur cette page. Pourquoi ce besoin dispose de 13 syntaxes différentes actuellement? Je remarque qu'il y a déjà beaucoup de syntaxes de wiki/forums qui je pense ont été toutes développées a peu près en même temps (ou alors c'est une syndrome Not Invented Here?). Mais quand est-il pour les syntaxes purement orientées document texte? Pourquoi tout le monde y va de son projet? Sont-ce des besoins/buts différents?

Des noms comme "headers.py", "tags.py", pour des utilisateurs béotiens, ça ne veut pas dire grand chose.

D'ailleurs ils n'ont même pas besoin de savoir ce que c'est. Par contre un développeur aura une chance de trouver par lui-même ce qu'il cherche d'après ces noms. C'est toujours utile de permettre aux nouveaux contributeurs de pouvoir facilement rentrer dans le code. Bon en même temps, 6k lignes c'est gros pour un seul fichier, mais quand même pas énorme pour la taille du programme.

Merci patrick_g pour une autre bonne dépêche sur le noyau.
Comme dit plus haut, les changements incorporés dans cette version semblent moins spectaculaire que dans d'autres.

Néanmoins cette dépêche m'a permis de découvrir coccinelle qui permet de refactoriser du code C simplement et à grande échelle. On démarre d'un patch ou l'on a déjà fait le travail de refactoring une fois, et puis il n' a plus qu'à le généraliser pour en faire un patch sémantique. L'idée est géniale.

[ma vie=on]
Ça répond à un besoin actuel que j'ai avec du code ... Java. Si ce même outil existait en Java j'en serais ravi.

Pour le moment je fais ca a base de regex, mais on se lasse rapidement de rajouter des \s ou même (?: |\t) à tout bout de champ, et du fait que l'outil ne comprenne pas le code source.

Un collègue m'avait présenté RefactoringNG [http://kenai.com/projects/refactoringng], mais ca ne correspondait pas a ce que je voulais, notamment à cause de l'absence de l'opérateur.... de Coccinelle qui abstrait n'importe quel code source.

Si vous connaissez des solutions, n'hésitez pas à me les présenter.
[ma vie=off]

et tu ne dois pas citer les contributeurs dans les sources de ton logiciel distribué peut être ?

Ben justement: Non.

Seule la licence BSD originelle te forçait a le faire. Mais cette clause a finalement été supprimée car elle vient en contradiction avec le libre.

Les licences libre ou open source (voir la définition que je t'ai proposé dans un autre commentaire) place le curseur du coté de l'utilisateur qui n'a pas à supporter les excentricités/caprices du développeur original.

La clause de publicité de Zimbra est un enquiquinement pour les utilisateurs qui ne peuvent plus redistribuer le logiciel librement sans se référer ad vitam æternam à Zimbra.

L'acception généralement utilisée ici est:
- libre = libre selon la FSF (Free Software Guidelines)
- open source = utilise une licence approuvée par l'OSI (Open Source Initiative) ou a la limite les Debian Free Software Guidelines (DFSG)

Tout le reste est considéré comme non libre et non open source. D'ailleurs parmi les licences Shared Source de Microsoft je crois qu'une seule a été reconnue Open Source par l'OSI.

Donc la licence ZPL avec les restrictions qu'elle impose (obligation d'utiliser leur logo, c'est de la pub qui ne dit pas son nom) n'est ni libre ni open source (Cela ressemble a la licence BSD originelle qui n'est ni libre ni Open Source). Dire le contraire ici, c'est s'exposer a un moinssage en règle, mais j'ai cru comprendre que tu as la tête dure ;)

Malheureusement, le simple fait d'entrer dans l'économie te lie de facto a des choses qui ne te plaisent pas dans cette économie. Par exemple, tu achètes ton pain a ton boulanger qui lui va faire ses courses dans un bon gros supermarché (pas biocoop) car il n'a pas la même sensibilité que toi sur ce sujet. Ensuite le gros supermarché fait appel a Thales service pour son informatique interne (par exemple). Thales service fait partie d'un groupe disposant d'une branche militaire. Te voila donc lier a un consortium militaire!!

Bref, je ne comprends pas que ce que tu appliques a ton boulanger (je ne lui dicte pas ce qu'il doit faire) ne s'applique pas a flattr (qui est tout petit pour l'instant, même si ca pourrait changer).


En ce qui concerne les livrets:
- le livret A sert a des missions d'intérêt général tels que la construction de HLM via la caisse des dépôts ( http://fr.wikipedia.org/wiki/Livret_A#Collecte_et_utilisatio(...) )
- le LDD (ancien Codevi) finance les PME du secteur secondaire ( http://fr.wikipedia.org/wiki/Livret_de_d%C3%A9veloppement_du(...) )

Malheureusement ce n'est pas le cas des frais bancaires qui selon la banque ou tu te trouves vont avoir une finalité différente. Entreprises cotées en bourse: investissement sur les marchés boursiers? (SoGé?), dividendes? (BNP?), etc.
Banques mutuelles, lire les statuts de la mutuelle, etc.


Bref, si on veut tout suivre, il y a de quoi devenir fou ou schizophrène. A noter qu'il existe tout de même des banques qui reversent une partie des intérêts de tes livrets a des projets d'économie solidaire ou pour faire du micro crédit. Je ne me souviens plus leur nom, c'est triste, snif...

Je ne crois pas que quelque chose d'autre va prendre sa place, car si ca doit aller sur le web, alors SVG et Canvas vont être utilises. Ils vont être très bien pris en charge par tous les navigateurs majeurs dans un futur très proche.

Pour tout le reste GIF sera encore utilisé mais les utilisations qui restent semblent plus marginale.

Bravo pour ton logiciel et pour ta réactivité. Merci de partager ce travail sympathique car c'est toujours sympa de voir le démarrage d'un projet.

Ne te laisse pas démoraliser par les esprits chagrins qui ont loupé tout l'historique de ton logiciel (pourquoi il existe) et de cette dépêche (elle a été créée - ils ont eu raison- alors que tu n'en avais pas spécialement envie).

Bonne continuation!

Neelie Kroes [...] déclarait il y a quelques temps que « La Recherche et le Développement réalisés à des fins de support de solutions propriétaires est un gaspillage d'argent public. »
Je l'aime bien cette femme. Elle a tout compris :)

"[THINQ.co.uk] UK Gov IT chief backs open source, small business"
Est ce que la France avait finalement créé un Small Business Act a la française (une loi garantissant aux PME de se voir attribuer un certain pourcentage des appels d'offres), ou pas?

Justement: on ne peut pas prendre de photo d'un bâtiment original sans en demander l'autorisation expresse a l'architecte.