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
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.
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.
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 :)
- 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.
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:
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).
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.
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.
A l'heure du "Web 2.0" et des pseudo applications lourdes en html, tu n'a donc pas pensé comme "protocole universel pour se connecter à Nestor" de faire un site web ajax ergonomiquement bien foutu pour que même madame Michu s'y retrouve ? :)
Et même si tu ne veux pas avoir une bonne interface graphique pour gérer tout ça, ce qui serait tout de même pratique, actuellement, avec un peu de dev, rien n'empeche de faire même une console complète (avec autocompletion, commandes de tail -f qui passe, etc. ), etc. dans une page web (merci le reverse ajax).
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.
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.
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.
Ouais ils ont droit de le croire, mais au moins c'est pas vrai pour tout le monde. Ils auraient sortie les 900 20Go en meme tps que les 12 Go tournant sous XP, au lieu de sortir les 20 Go des semaines^Wmois plus tard, j'aurai pas acheté un Acer (suis pas fan de la marque).
Mais au final merci Asus de cette politique, puisque l'A1 me convient bien mieux qu'un 900 (notamment le clavier), et comme faut attendre noël (au moins la rentrée, mais tels qu'ils sont partis, il nous referont le coup de la sortie XP uniquement pendant des semaines/mois...) pour avoir les 901, suis content de mon achat, c'est finalement plus l'A1 l'héritier direct du 701 (reste petit, très léger, ssd, linux...) que les 900 ou 1000.
Par contre, une fois décoché l'utilisation des 2 drivers "restricted" d'Ubuntu, pensez bien à redémarrer (ou à enlever les modules à coup de rmmod je suppose), sans quoi ça marche pas :P
J'ai rajouté le modprobe dans mon rc.local, car quand j'ai essayé dans modprobe.d j'ai eut l'impression que ça a mis les drivers précédents (sans doute sont ils dans le ramdisk, et comme je l'ai pas refabriqué...), en tout cas ça fonctionnait pas.
J'ai acheté aussi un Aspire One samedi chez GrosBill, en tentant la barette de RAM 2 Go ...
Je confirme, rajouter une barette est un peu inchiable, et manifestement le Bios (ou une autre raison que je ne vois pas) est verrouillé pour n'accepter que des barrette 1 Go max. C'est _très_ dommage et pour moi c'est un gros mauvais point pour Acer.
J'attendrai que quelqu'un trouve une solution pour pouvoir mettre des 2Go avant d'y passer du coup. J'irai me faire rembourser ma barrette 2Go mardi pour en prendre une 1Go à la place, et je redémonterai une dixième fois la machine (oui, pour vérifier que ce n'était pas un problème de branchement quand j'ai mis la RAM, j'ai du beaucoup le monter/démonter).
Sinon mes sentiments corroborent les tiens : je trouve le clavier très très bien, il ne m'a nécessité aucune adaptation et je peux déjà taper dans le noir ! De même l'écran est plutôt bon et le côté glossy ne m'a pas dérangé, même en extérieur.
Pour l'OS, dommage que je n'ai pas trouvé le mode avancé hier, j'ai passé ma soirée^Wnuit à installer une autre distribution, frustré par celle d'origine. Le problème est qu'il faut installer sans CD, et même si le boot réseau est possible, je ne m'y suis jamais tenté, et je pense que j'aurai galéré un poil pour le faire. Du coup j'ai converti des isos d'install pour les adapter pour clef USB.
Pour info, même s'il m'a fallu un peu de temps pour le comprendre, il suffit de formatter une clef USB (ou une SDHC dans un lecteur USB, ça marche aussi, mais pas direct en l'utilisant dans la machine) en Fat32, mettre la partition comme bootable, faire un cat /usr/share/syslinux/MBR.bin > /dev/sdX, puis utiliser "syslinux" sur le /dev/sdX pour l'installer, puis copier tous les fichiers d'une ISO sur la clef (y compris les fichiers cachés !). Il suffit après de renommer le répertoire isolinux en syslinux, et isolinux/isolinux.cfg en syslinux/syslinux.cfg (des fois il faut editer un peu le fichier syslinux.cfg pour virer des "/cdrom/" qui trainent aussi).
J'ai donc commencé par tenter l'install d'une Mint 5-> echec sur un module noyau, passe pas en failsafe o_O. Le module en question s'occupe de récupérer la température du processeur je crois, ca fait un oops kernel et le boot ne continue pas. Du coup me suis rabattu sur une OpenGEU (j'hésite à présent mais je pensais utiliser E17), même problème. Du coup j'ai voulu tenter une ELive de développement (jamais essayé, mais ça à l'air très bien), mais ça utilise Grub pour booter, c'est loin d'être un reproche mais comme j'avais déjà des trucs à base de isolinux/syslinux, j'ai décidé de continuer sur les distribs basé dessus dans un premier temps.
J'ai fini par tenter "bêtement" une Ubuntu Hardy Heron(la prochaine était l'openSUSE 11, puis la mandriva 2008.1), et là, bonne surprise: les dérivés de la hardy ne s'installent pas, mais elle, oui, sans problème. Je n'ai pas configuré le wifi à l'install mais ma distrib m'indique qu'elle utilise un pilote proprio (Atheros) j'en conclu qu'elle sait s'en servir.
Une fois l'installation terminée, redémarrage sur Ubuntu : bonne surprise, les effets du bureau sont là, et fonctionnent très bien, même en les mettant en mode avancé. Je crains que ca bouffe un peu en perf batterie mais c'est très agréable. L'oS tourne bien mais un GNome normal sur 512 avec effets ça bouffe de la RAM et les 512 dont je dois em contenter pour le moment ne sont pas très large (rien de lancé, plus que 33% de RAM dispo). Par contre, j'ai rencontré un petit problème ... pas de Wifi !
Je ne suis pas un pro du Wifi sous linux, je crois que c'est la première fois que j'ai un portable Wifi à moi, et pour le reste j'utilise du bon vieux RJ45, du coup pour le moment je suis un peu bloqué, je n'ai encore lu aucune doc sur l'install du wifi quand il ne marche pas d'entrée, quelqu'un aurait une doc à me conseiller ?
Voilà mon expérience pour le moment, à vous les Studios!
Oui, c'est parcequ'ils ont décidé de mettre un processeur et de coder des firmware à l'arrache sans faire de tests unitaire/intégration, etc.
Pire, ils ne font (au moins il y a 2 ans) pas de redondance dans les resultats obtenu par le processeur, alors qu'il gère toujours plus de chose. Des amis travillant à infineon bossaient sur des DSPs "double" avec controle de cohérence à la sortie pour améliorer ça ... néanmoins avoir 2 DSPs implémentés à 2 endroits différents de la voiture me paraitrait plus sage.
C'est pas le cout de doubler l'electronique qui est grand (au final ca coute le prix du sable + le developpement pour quelques millions d'unités), pourtant il ne le font pas, et perso, ça m'inquiète quand à la fiabilité... Pour avoir des serveur web toujours dispo, on les redonde tout le temps, idem pour les base de données. Par contre pour faire en sorte qu'un régulateur de vitesse fasse pas de la merde, là, bah ya rien, c'est que la vie de quelques humains qui est en jeu après tout...
[^] # Re: Des réponses
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 4.
- 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
[^] # Re: et SVK
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 2.
[^] # Re: et SVK
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 2.
[^] # Re: SVN c'est has been :)
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 2.
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.
[^] # Re: SVN c'est has been :)
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 5.
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 :)
[^] # Re: SVN c'est has been :)Ba
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 2.
[^] # Re: et SVK
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 1.
http://weblogs.mozillazine.org/preed/2007/04/version_control(...)
[^] # Re: SVN c'est has been :)
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 4.
- 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).
# SVN c'est has been :)
Posté par Temsa (site web personnel) . En réponse au journal Migrer de Svn vers Bzr ?. Évalué à 10.
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.
[^] # Re: C'était mieux avant.
Posté par Temsa (site web personnel) . En réponse à la dépêche Évolutions sur LinuxFr. Évalué à 5.
[^] # Re: en attendant ...
Posté par Temsa (site web personnel) . En réponse au journal Firefox: Encore plus vite que vite. Évalué à 2.
Vivement que le bug qui empêche de compiler en 64 soit règlé, que je puisse tester !
# Option de ne pas mettre de vote possible
Posté par Temsa (site web personnel) . En réponse au journal Pour le retour des journaux de seconde page. Évalué à 4.
Qu'en pensez-vous ?
[^] # Re: idée toute simple
Posté par Temsa (site web personnel) . En réponse au journal Comment tuer un développeur de LL*. Évalué à 3.
Merci à toi en tout cas, il m'a bien rendu service ton CMS !
# Un serveur Web ?
Posté par Temsa (site web personnel) . En réponse au journal Nestor, serveur domestique. Évalué à -1.
Et même si tu ne veux pas avoir une bonne interface graphique pour gérer tout ça, ce qui serait tout de même pratique, actuellement, avec un peu de dev, rien n'empeche de faire même une console complète (avec autocompletion, commandes de tail -f qui passe, etc. ), etc. dans une page web (merci le reverse ajax).
[^] # Re: Modularisation?
Posté par Temsa (site web personnel) . En réponse au journal Vers une version Qt de Firefox. Évalué à 3.
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.
[^] # Re: Tuto d'installation d'Ubuntu sur Aspire One
Posté par Temsa (site web personnel) . En réponse au journal Aspire Aspire One - Premières impressions. Évalué à 1.
# Les bons CMS sont peu nombreux
Posté par Temsa (site web personnel) . En réponse au journal Dans la jungle des CMS.... Évalué à 5.
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.
# Friendfeed & Yahoo Pipe
Posté par Temsa (site web personnel) . En réponse au journal Suivre vos amis grâce à Whoisi .... Évalué à 2.
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.
[^] # Re: Puisqu'on est dans le troll
Posté par Temsa (site web personnel) . En réponse au journal Un pc portable ≠ eee. Évalué à 3.
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) :)
[^] # Re: A propos de l'eeepc
Posté par Temsa (site web personnel) . En réponse au journal Aspire Aspire One - Premières impressions. Évalué à 2.
Mais au final merci Asus de cette politique, puisque l'A1 me convient bien mieux qu'un 900 (notamment le clavier), et comme faut attendre noël (au moins la rentrée, mais tels qu'ils sont partis, il nous referont le coup de la sortie XP uniquement pendant des semaines/mois...) pour avoir les 901, suis content de mon achat, c'est finalement plus l'A1 l'héritier direct du 701 (reste petit, très léger, ssd, linux...) que les 900 ou 1000.
[^] # Re: Moi aussi :)
Posté par Temsa (site web personnel) . En réponse au journal Aspire Aspire One - Premières impressions. Évalué à 2.
http://brunoabinader.blogspot.com/2008/05/atheros-ar5bxb63-o(...)
Par contre, une fois décoché l'utilisation des 2 drivers "restricted" d'Ubuntu, pensez bien à redémarrer (ou à enlever les modules à coup de rmmod je suppose), sans quoi ça marche pas :P
J'ai rajouté le modprobe dans mon rc.local, car quand j'ai essayé dans modprobe.d j'ai eut l'impression que ça a mis les drivers précédents (sans doute sont ils dans le ramdisk, et comme je l'ai pas refabriqué...), en tout cas ça fonctionnait pas.
[^] # Re: Garantie
Posté par Temsa (site web personnel) . En réponse au journal Aspire Aspire One - Premières impressions. Évalué à 2.
# Moi aussi :)
Posté par Temsa (site web personnel) . En réponse au journal Aspire Aspire One - Premières impressions. Évalué à 5.
Je confirme, rajouter une barette est un peu inchiable, et manifestement le Bios (ou une autre raison que je ne vois pas) est verrouillé pour n'accepter que des barrette 1 Go max. C'est _très_ dommage et pour moi c'est un gros mauvais point pour Acer.
J'attendrai que quelqu'un trouve une solution pour pouvoir mettre des 2Go avant d'y passer du coup. J'irai me faire rembourser ma barrette 2Go mardi pour en prendre une 1Go à la place, et je redémonterai une dixième fois la machine (oui, pour vérifier que ce n'était pas un problème de branchement quand j'ai mis la RAM, j'ai du beaucoup le monter/démonter).
Sinon mes sentiments corroborent les tiens : je trouve le clavier très très bien, il ne m'a nécessité aucune adaptation et je peux déjà taper dans le noir ! De même l'écran est plutôt bon et le côté glossy ne m'a pas dérangé, même en extérieur.
Pour l'OS, dommage que je n'ai pas trouvé le mode avancé hier, j'ai passé ma soirée^Wnuit à installer une autre distribution, frustré par celle d'origine. Le problème est qu'il faut installer sans CD, et même si le boot réseau est possible, je ne m'y suis jamais tenté, et je pense que j'aurai galéré un poil pour le faire. Du coup j'ai converti des isos d'install pour les adapter pour clef USB.
Pour info, même s'il m'a fallu un peu de temps pour le comprendre, il suffit de formatter une clef USB (ou une SDHC dans un lecteur USB, ça marche aussi, mais pas direct en l'utilisant dans la machine) en Fat32, mettre la partition comme bootable, faire un cat /usr/share/syslinux/MBR.bin > /dev/sdX, puis utiliser "syslinux" sur le /dev/sdX pour l'installer, puis copier tous les fichiers d'une ISO sur la clef (y compris les fichiers cachés !). Il suffit après de renommer le répertoire isolinux en syslinux, et isolinux/isolinux.cfg en syslinux/syslinux.cfg (des fois il faut editer un peu le fichier syslinux.cfg pour virer des "/cdrom/" qui trainent aussi).
J'ai donc commencé par tenter l'install d'une Mint 5-> echec sur un module noyau, passe pas en failsafe o_O. Le module en question s'occupe de récupérer la température du processeur je crois, ca fait un oops kernel et le boot ne continue pas. Du coup me suis rabattu sur une OpenGEU (j'hésite à présent mais je pensais utiliser E17), même problème. Du coup j'ai voulu tenter une ELive de développement (jamais essayé, mais ça à l'air très bien), mais ça utilise Grub pour booter, c'est loin d'être un reproche mais comme j'avais déjà des trucs à base de isolinux/syslinux, j'ai décidé de continuer sur les distribs basé dessus dans un premier temps.
J'ai fini par tenter "bêtement" une Ubuntu Hardy Heron(la prochaine était l'openSUSE 11, puis la mandriva 2008.1), et là, bonne surprise: les dérivés de la hardy ne s'installent pas, mais elle, oui, sans problème. Je n'ai pas configuré le wifi à l'install mais ma distrib m'indique qu'elle utilise un pilote proprio (Atheros) j'en conclu qu'elle sait s'en servir.
Une fois l'installation terminée, redémarrage sur Ubuntu : bonne surprise, les effets du bureau sont là, et fonctionnent très bien, même en les mettant en mode avancé. Je crains que ca bouffe un peu en perf batterie mais c'est très agréable. L'oS tourne bien mais un GNome normal sur 512 avec effets ça bouffe de la RAM et les 512 dont je dois em contenter pour le moment ne sont pas très large (rien de lancé, plus que 33% de RAM dispo). Par contre, j'ai rencontré un petit problème ... pas de Wifi !
Je ne suis pas un pro du Wifi sous linux, je crois que c'est la première fois que j'ai un portable Wifi à moi, et pour le reste j'utilise du bon vieux RJ45, du coup pour le moment je suis un peu bloqué, je n'ai encore lu aucune doc sur l'install du wifi quand il ne marche pas d'entrée, quelqu'un aurait une doc à me conseiller ?
Voilà mon expérience pour le moment, à vous les Studios!
[^] # Re: portnawak...
Posté par Temsa (site web personnel) . En réponse au journal Google offre un format de donnée sous licence Apache. Évalué à 3.
[^] # Re: Toujours la même chose
Posté par Temsa (site web personnel) . En réponse au journal Hoax ou pas hoax ?. Évalué à 2.
Pire, ils ne font (au moins il y a 2 ans) pas de redondance dans les resultats obtenu par le processeur, alors qu'il gère toujours plus de chose. Des amis travillant à infineon bossaient sur des DSPs "double" avec controle de cohérence à la sortie pour améliorer ça ... néanmoins avoir 2 DSPs implémentés à 2 endroits différents de la voiture me paraitrait plus sage.
C'est pas le cout de doubler l'electronique qui est grand (au final ca coute le prix du sable + le developpement pour quelques millions d'unités), pourtant il ne le font pas, et perso, ça m'inquiète quand à la fiabilité... Pour avoir des serveur web toujours dispo, on les redonde tout le temps, idem pour les base de données. Par contre pour faire en sorte qu'un régulateur de vitesse fasse pas de la merde, là, bah ya rien, c'est que la vie de quelques humains qui est en jeu après tout...