Pour moi l'avantage intrinsèque des DVCS c'est pas de pouvoir committer depuis sa boulangerie, mais ce qui en découle :

- Des merges faciles et bien foutus

- Des refactoring qui posent pas de problème et qui ne nécéssitent souvent même pas une branche.

- La possibilité de maintenir un patch aisément par rapport, par exemple, à un produit open source (exemple typique: cablage du sso interne sur un forum php libre, ou maintenance d'un patch en attendant qu'un mainteneur l'intègre) ou un produit d'entreprise (ex: gérer le spécifique d'un client dans un repo dans lequel on importe les modifs du produit de base au fur et à mesure).

- Facilite le libre car tout un chacun peut se faire son propre repo, son propre hack à partir d'un projet libre, et le présenter facilement au mainteneur une fois que celui-ci fonctionne bien. Ca facilite grandement la méritocratie, et ne demande pas à quelqu'un de travailler dans de mauvaises conditions ou de devoir lui faire confiance sans savoir si on peut en lui filant des accès dev qu'il n'a pas prouvé mériter.

- La plupart sont plus rapides que les VCS habituels

- La plupart gèrent correctement les fichiers binaires

[ Répondre ]

s/1 et demi/un an et demi/g

[ Répondre ]

Je confirme, dans ma boite on passe tous les cvs vers svn, mais je me bat pour imposer les DVCS. Car après 1 et demi de cvs et un 1 et demi de svn (et plusieurs mois de Mercurial en parallèle), je connais bien leurs défauts.

[ Répondre ]

Je tenterai de faire des tests avec la 1.5, mais je tiens à faire remarquer que la plupart des repo que je connais tournent en svn 1.3 ou 1.4, tout simplement parce que les serveurs tournent sur des version de distrib "stables" souvent antédéluviennes.

Mais je suis loin d'être sur que tout soit réglé, le gros problème comme c'est bel et bien la gestion du move qui est un add + delete.
cf. d'ailleurs les gens qui ont fouillés un peu plus svn 1.5 que moi.

[ Répondre ]

Mercurial (son petit nom: Hg, tu trouveras facilement TortoiseHg et MercurialEclipse, pour Netbeans, c'est carrément distribué avec puisque Netbeans et OpenJDK sont développé avec Mercurial pour VCS).

Marche très bien sur tous les OS, a de bonnes intégrations, est très rapide, fait juste ce qu'on veut. Terrible quoi :)

[ Répondre ]

Bah c'est un pseudo-DVCS qui garde un certain nombre des défauts de SVN... Bref ...

[ Répondre ]

C'est d'ailleurs tellement bien que Mozilla est passé a Mercurial au lieu de CVS \o/

http://weblogs.mozillazine.org/preed/2007/04/version_control(...)

[ Répondre ]

De rien, je précise donc :

- Le refactoring de répertoire doit pouvoir fonctionner a peu pres correctement (avec un svn move ou un truc du genre, du coup pour ce problème, ça vient d'un défaut de svn dont je vais reparler, mais pas forcément de la ligne de commande, plutôt des interfaces qui se greffent dessus), néanmoins essais dans Eclipse, Nautilus ou un Explorateur windows d'aller dans un répertoire contenant lui même plein de sous répertoires qui sont eux meme committé. Tu fais un couper-coller pour le mettre dans un autre répertoire quelconque lui même déjà sous SVN.

Là, c'est le drame : tu te payes pleins d'erreurs pas possibles, voire parfois si tu commit un fichier dans un sous repertoire de cette arboresence, j'ai l'impression que tu commit tout ça à l'acncien endroit.

Pourquoi ? c'est simple. A l'instar de cvs, svn, créé un répertoire .svn dans chaque répertoire contenant les informations sur le répertoire courant, et l'endroit où il se trouve dans l'arborescence du projet, avec notre copier-coller, on a gardé ce répertoire, qui contient désormais les anciennes informations de où se trouve nos répertoire, pas de bol c'est faux.

Du coup si vous voulez committer l'arbo à la nouvelle place, il ne vous reste plus qu'a vous supprimer tous les ".svn" de tous les sous répertoires. Enfin bon, la fois d'après vous aurez été plus malin, et vous ferez directement un svn export ou un svn move, mais l'action naturelle ne fonctionne pas, et tous les nouveaux de ma boite se font piéger systématiquement.

En comparaison, les hg, git ou bzr ont bien un equivalent du ".svn", sauf qu'il n'y en a qu'à la racine du checkout(donc un copier-coller n'embarque pas des information invalides), et ils retrouvent leur bébé même après avoir déplacé un fichier, en retrouvant tout seul son historique (je suppose que ca se base sur un hash des fichiers pour les retrouver, mais j'ai pas verifié). Bref, ils font juste ce qu'ils doivent faire.



- 2e point, les merge avec des refactoring: Là je citerai le redbook SVN ( http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.branchm(...) ) :

A common desire is to refactor source code, especially in Java-based software projects. Files and directories are shuffled around and renamed, often causing great disruption to everyone working on the project. Sounds like a perfect case to use a branch, doesn't it? Just create a branch, shuffle things around, then merge the branch back to the trunk, right?

Alas, this scenario doesn't work so well right now, and is considered one of Subversion's current weak spots. The problem is that Subversion's update command isn't as robust as it should be, particularly when dealing with copy and move operations.

When you use svn copy to duplicate a file, the repository remembers where the new file came from, but it fails to transmit that information to the client which is running svn update or svn merge. Instead of telling the client, “Copy that file you already have to this new location”, it instead sends down an entirely new file. This can lead to problems, especially because the same thing happens with renamed files. A lesser-known fact about Subversion is that it lacks “true renames”—the svn move command is nothing more than an aggregation of svn copy and svn delete.


Dans les faits : créé une branche pour pouvoir réorganiser tes fichiers, déplace les (même avec un svn move et pas un copier-coller, ça change rien sauf le problème des .svn) puis commit dans ta branche, renommes en certains, puis commit dans ta branche, après corrige les chemins qu'il y a dans les fichiers (ça peut être les noms de package en java, ou le chemin relatif vers un répertoire), puis commit.dans ta branche.

Vu que tu a créé une branche, c'est parce que faire ce boulot et corriger tous les fichiers devait te prendre au moins 2-3 jours pendant lesquels tu ne pouvais bloquer les développements de tes collègues, donc qu'on fai tes collègues pendant ce temps ? Ils ont bossé sur les même fichiers que toi dans l'ancienne arborescence. Là on se dit, c'est pas grave, SVN va comprendre que j'ai déplacé, renommé les fichiers en question et me proposera de merger mes changements avec ceux de mes collègues.

Alors là tu te mets à regarder comment faire ton merge, et déjà, t'y comprends rien parce qu'il faut utiliser la version n-1 de ton développement pour le merge, et mettre des référence sur quel est l'origine de la branche et quel et la version avec laquelle on veut merger.

Et là, tu tombes dans ce cas :

For example, suppose that while working on your private branch, you rename integer.c to whole.c. Effectively you've created a new file in your branch that is a copy of the original file, and deleted the original file. Meanwhile, back on trunk, Sally has committed some improvements to integer.c. Now you decide to merge your branch to the trunk:

$ cd calc/trunk

$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
D integer.c
A whole.c

This doesn't look so bad at first glance, but it's also probably not what you or Sally expected. The merge operation has deleted the latest version of integer.c file (the one containing Sally's latest changes), and blindly added your new whole.c file—which is a duplicate of the older version of integer.c. The net effect is that merging your “rename” to the branch has removed Sally's recent changes from the latest revision!

This isn't true data-loss; Sally's changes are still in the repository's history, but it may not be immediately obvious that this has happened. The moral of this story is that until Subversion improves, be very careful about merging copies and renames from one branch to another.

Bref, dans certains cas, le merge gueule pas (enfin ça, c'est rare) et il vire juste les changements que tes collègues ont fait... Mais bon c'est pas tout :

To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.

So how do we use svn merge in this scenario? Remember that this command compares two trees, and applies the differences to a working copy. So to receive the changes, you need to have a working copy of the trunk. We'll assume that either you still have your original one lying around (fully updated), or that you recently checked out a fresh working copy of /calc/trunk.

But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user! Since svn merge operates like svn diff, comparing the latest trunk and branch trees will not merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the removal of trunk changes that never happened on your branch.


Bon, par manque de temps(je dois partir au boulot), je vais te laisser lire la suite du redbook pour voir tous les problème qu'on se prend dans la gueule avec SVN. Mais pour résumer, c'est pas naturel, pas pratique, ça marche mal, et grossomodo il faut te faire les merges de fichier déplacé, renommés et retravaillé de chaque côté entièrement à la main, merci SVN...

Pendant ce temps là, tu prend un DVCS (bzr, hg ou git, mais me parlez pas de svk). Eux, par nature, comme on doit toujours pouvoir merger 2 repositories facilement sont obligé de gérer correctement ces merge avec déplacement / renommage /modification de fichier. en bref, ça se fait tout seul, et si jamais il y a un conflit entre le 2 code, seul les lignes impactée sont présentées par l'interface de merge, même si les fichiers n'ont rien à voir et ne sont plus du tout au même endroit. Le DVCS fait son job et retrouve l'historique des modifications pour permettre de faire le merge, bref, exactement ce qu'on lui demande.

Merger une branche avec le tronc (représentant 3-4 jours de travaille elle même) dans svn sur un projet conséuqent bloque les developpement de tout le monde pendant 1/2 journée pour le merge voire 1 journée, de plus vous aurez probablement quelques régressions fonctionnelles sur le code developpé sur le tronc, et il vous faudra tout revérifier derrière. Je suis désolé mais je trouve ça minable, surtout quand un hg, bzr ou git règle ca en 5 minute pour le même travaille. C'est tellement vrai que je connais des gens qui font les merge de branche sur svn via git parce que ça leur fait gagner beaucoup de temps.

Il parait que svn 1.5 doit arranger pleins de choses, néanmoins pour moi il est tellement à côté de la plaque au niveau de mes besoins quotidiens que je n'ai même pas envie de lire la doc de la super interface pas logique qu'ils ont du nous pondre pour gérer ça (le coup de la version n-1 à noter sur un papier pour un merge ... Ca mérite un coup de boule pour celui qui a pensé à un truc aussi pas logique par rapport a l'utilisateur, je pense qu'à la prochaine version il devrait prendre prendre 1+sqrt(5)/2 fois le numerio de version arrondi au dessus, ce serait moins pratique encore).

[ Répondre ]

Tu ne rencontres peutêtre pas toutes ces problèmatique vu ton utilisation, mais d'une manière générale :

Pourquoi passer à autre chose que SVN ?

- SVN n'aime pas les refactorings de répertoire. Mine de rien, c'est facilement handicapant.

- la gestion des branches de SVN, et particulièrement les rennommages / déplacements / compléments de fichiers déplacé est minable (meme le red book SVN le dit)

- si tu veux disons garder tes confs synchro entre 2 ordi avec quelques petites différences dedans (genre la conf spécifique à une machine), t'aura du mal avec SVN.

- supporte mal les fichiers binaires

Alors j'ai bien aimé Bazaar au début, mais dans le cadre dans le quel je souhaitai bosser, en cross platform, bzr était mauvais (la version Windows est bof, l'intégration des plugin doit passer par la version "python", c'est vite le bordel à gérer, notamment le plugin d'interaction avec SVN, car il faut aussi un SVN patché).

Du coup Git est pas mal car très fourni, mais windows (et sans doute Mac aussi) reste(nt) un(^Wdes) citoyen(s) de seconde zone dessus et en dehors de l'interface fournie avec l'install(qui se cable un peu comme un "tortoisegit" dans l'explorateur), il n'y a pratiquement aucune intégration avec ce DVCS sous Windows.

Et la j'ai decouvert Mercurial, un vrai bonheur :) plus rapide que Bazaar, très fourni en plugins, choisi par Mozilla et Sun pour gérer d'énormes soft multi-plateforme, il tourne aussi bien sous Linux que sous Windows, s'intègre autant dans l'Explorateur que dans Nautilus que dans Maven que dans Eclipse que dans Netbeans (le gros de mon développement se fait en Java et Javascript, ces IDE conviennent parfaitement), import facile et rapide d'un repo SVN en gardant l'historique, il gère aussi les delta sur les fichiers binaires (je crois que Bzr et Git aussi, mais je ne suis pas sur), et les push/pull sont étonnament rapide (moins que git parait il, mais rien à voir avec Bzr ou SVN).

Pour un projet opensource, un DVCS c'est aussi : une facilité pour les nouveaux venu à proposer et maintenir des patch très facilement, à plusieurs même. C'est l'assurance d'avoir des merges bien foutus ( honnêtement le déplacement + renommage + ajout de contenu fonctionne super bien en merge), et de pouvoir travailler en petite équipe en marge d'un repo officiel, pour présenter par exemple un gros refactoring, ce qui au final est souvent nécessaire sur les projet, puisqu'en ce complexifiant, il faut ranger les fichiers autrement, etc.

Pour l'hébergement, on trouve pas mal de site de repo Mercurial, personnellement j'ai fini par utiliser http://assembla.com (c'est une forge, mais pas forcément centrée que sur le développement pure et dure, c'est plutôt bien), même s'il lui manque de pouvoir disposer de plusieurs repo pour le même projet (notamment pour gérer des branches sous forme de repo plutôt qu'en interne à un repo, ce que j'aime moins). Pour Git il y a surtout le fameux GitHub, très utilisé, et pour Bazaar je ne connais pas d'autre hébergement que Launchpad.

[ Répondre ]

Au contraire, elle permet de découvrir milles choses intéressantes sur le site que je ne regardai pas avant \o/

[ Répondre ]

Sous wine, il va a peu près aussi vite avec tracemonkey qu'en natif sans.

Vivement que le bug qui empêche de compiler en 64 soit règlé, que je puisse tester !

[ Répondre ]

Pour moi les journaux de seconde page , ça pourrait simplement être des journaux sur lesquels on autorise pas le "score", et qu'on le laisse à zéro par exemple.

Qu'en pensez-vous ?

[ Répondre ]

Je voulais un message plus "confidentiel" et j'avais pensé que suivi>administration me ferait un contact vers les admin. Pas de bol, c'est là en fait: http://linuxfr.org/team/ .

Du coup me retrouve en première page, c'était pas le but, va falloir que je m'habitue à ce nouveau site \o/

[ Répondre ]

Oh tiens, je l'ai utilisé celui-là il ya 2-3 ans (pendant 6mois environs pour un site de guilde WoW ...)!

Merci à toi en tout cas, il m'a bien rendu service ton CMS !

[ Répondre ]

Need Firefox-EFL !

Marre des pages qui rament une fois le zoom activé (et parfois même sans), notamment lors des scrolls...
Je ne comprend pas pourquoi ça fait ça vu que normalement le backend de rendu [1] est sensé exploiter l'accélération graphique[2] depuis FF3, non ?
Après je pense qu'il est possible que ce soit la manière dont Firefox gère ça qui produise cet effet.

J'ai beau être fan de FF au quotidien, j'attend encore une version correctement accélérée graphiquement et multithreadée (ou mieux, micro threadé), qu'on ne patisse pas des ressources utilisées par un onglet lorsque un autre onglet a besoin de ressources et a 3 coeur dispo sans les utiliser, je trouve ça rageant.


1: cairo: http://www.cairographics.org/
2: on note tout de meme que le backend OpenGL est experimental d'après le site de cairo, mais même sans, il est bien sensé utiliser les accélérations graphiques disponibles...
Vu que ça semble ne pas marcher top pour l'accélération, pourquoi Cairo a pas un backend EFL? ca lui ferait sans doute du bien.

[ Répondre ]

Mort de rire, mon Aspire One est aussi sur Ubuntu (et j'en suis très très content), et je suis aussi lyonnais \o/

[ Répondre ]

Il y a très peu de bons CMS libre, puissants et flexibles, à mon avis, ils se comptent pratiquement sur les doigts d'une seule main.

D'ailleurs la plupart tournent autour de la JCR170 (http://en.wikipedia.org/wiki/Content_repository_API_for_Java(...) ou des même principes. Du coup pas mal sont aussi à la limite de la GED, ou vice versa (Alfreco comme exemple inverse, potentiellement on peut faire du CMS avec).

Je dirai que le problème de la plupart des CMS, c'est qu'ils sont en PHP et donc se payent beaucoup de tare dés la base (rare sont les developpements en couche, le MVC, les DAO, etc. dans ce langage... j'en ai assez écrit /"hacké" pour le savoir, j'avais moi même fait mon propre CMS light en php pour un de mes sites il y a quelques années).

J'en connais un, Igenko, basé sur de bonnes techno (à part Flex, beurk :P), bien structuré et bien fait, mais il n'est pas fini, loin de là ( http://code.google.com/p/igenko/ ) et on a pas encore vu la 0.5 (pour la rentrée ?) même si les dev avancent bien de ce que j'en sais. De plus comme tout truc en java, ça tourne pas chez la plupart (totalité ?) des hébergeurs gratuits.

[ Répondre ]

Friendfeed permet le même genre de chose, sauf qu'on peut s'auto renseigner aussi (les amis qui veulent vous suivre sans que vous renseigniez vos flux fabriquent des "amis imaginaires").

Dans une optique différente, plus complexe mais plus puissante (sauf qu'elel n'autorise pas les commentaires comme friendfeed) : yahoo pipe, ca permet de programmer une aggregation de plusieurs flux pour n'en fait plus qu'un. C'est très puissant, mais demande un certains temps pour tout comprendre.

[ Répondre ]

es ASUS (par contre en ce moment toujours, fuyez leur cartes mères).

Petit à côté, ça dépend de la carte mère, le haut de gamme est plutôt bien (en tout cas ma dernière est assez terrible) :)

[ Répondre ]