Le basculement de KDE vers Subversion est terminé

Posté par (page perso) . Modéré par Florent Zara.
Tags :
1
11
mai
2005
KDE
KDE est un des projets majeurs du monde du logiciel libre. Ce bureau complet est développé à un rythme rapide par des codeurs du monde entier et il requiert donc l'utilisation intensive d'un outil de gestion de code performant. Jusqu'à présent c'était le vénérable CVS (Concurrent Versions System) qui était utilisé mais dès octobre 2004 les leaders du projet KDE avaient décidé de changer et de basculer vers le plus moderne Subversion.

Cette transition délicate est maintenant terminée (depuis le 5 mai) et le travail a repris de plus belle sur les serveurs KDE pour pouvoir nous proposer un bureau encore plus performant et complet. Quelle est la raison de ce basculement vers Subversion ?
Selon le message de Tobias Koenig datant du 10 octobre cette transition est nécessaire pour préparer l'arrivée du futur KDE 4 ce qui va entraîner beaucoup de ménage ("move" et "rename" de branches) qu'il est très difficile d'effectuer avec CVS.

De plus les améliorations de SVN apportent un bénéfice supplémentaire non négligeable par rapport à CVS (le message évoque les "dépôts cachés" sur des disques locaux pour éviter des connexions incessantes au serveur principal) et, cerise sur le gâteau, les commandes sont presque identiques entre les deux logiciels
Ce basculement de KDE vers Subversion est le plus grand jamais effectué et le script de conversion a tourné pendant 38 heures avant d'en finir ! L'archive KDE maintenant présente dans le dépôt Subversion représente 15 Go de données.

Enfin on peut noter que du coté du bureau Gnome c'est CVS qui reste la norme mais une discussion commence à apparaître pour effectuer également le basculement et une session sera consacrée à ce sujet lors des rencontres Gnome de Stuttgart à la fin de ce mois.
  • # Subversion vs GIT

    Posté par . Évalué à 1.

    Subversion étant maintenant au point depuis plus d'un an, on peut se demander si les raisons ayant poussé Linus Torvald à développer GIT sont bien fondées ?
    Puisque subversion dispose d'une architecture en couche,
    n'aurait il pas été possible de remplacer l'attaque de la base de donnée berkley par l'attaque du file système ?
    • [^] # Re: Subversion vs GIT

      Posté par . Évalué à 10.

      La réponse est non. Ce sont les auteurs de Subversion eux-mêmes qui le disent.

      voir http://subversion.tigris.org/subversion-linus.html(...)
    • [^] # Re: Subversion vs GIT

      Posté par . Évalué à 10.

      svn n'est pas adapté à la façon de fonctionner de Linus.

      En gros, Linus passe son temps à faire des merges d'arbre plutot que des patchs.

      "La première sécurité est la liberté"

      • [^] # Re: Subversion vs GIT

        Posté par . Évalué à 7.

        Et git apparemment est très rapide pour faire des merges d'arbre..

        Par contre, là ou je suis surpris c'est que le merge de fichier n'a pas l'air d'être le problème numéro 1 de Linus..
        Pourtant pour avoir joué au "mergeur" sur du CVS, c'est ch...^W pénible, et apparemment BK était assez bon sur ce sujet.

        Ceci dit, je ne vois pas comment BK pouvait être meilleur que le classique 3-way merge, mais je doit manquer d'imagination!

        PS: Je me demande si Mercurial a une chance contre git?
        • [^] # Re: Subversion vs GIT

          Posté par (page perso) . Évalué à 5.

          > je ne vois pas comment BK pouvait être meilleur que le classique 3-way merge, mais je doit manquer d'imagination!

          Je ne connais pas trop BK (jamais utilisé), mais le merge de base est une forme de 3-way merge.

          En fait, une des grosses difficultés, c'est plus la recherche de l'ancetre commun que le merge lui-même (qui est un problème relativement bien résolu aujourd'hui, même si il y a encore des cas ou on pourrait faire mieux). Pour ça, il faut garder un historique de qui a mergé qui, qui est une branche de qui, ... ce que CVS par exemple ne fait pas. Il faut aussi un système de nommage qui permette de garantir l'unicité du nom sans pour autant qu'il n'y ai d'autorité centralisée d'attribution des noms (l'information "j'ai mergé avec toto version 42" n'est intéressante que si il y n'y a qu'un seul "toto" au monde ...). D'ou les histoires de SHA1 pour git et les adresses email dans les noms d'archives GNU Arch.
          • [^] # Re: Subversion vs GIT

            Posté par . Évalué à 5.

            Tout n'est pas si simple en fait, ce problème dit "de la mémoire de merge" n'est pas encore complètement résolu, mais ca va venir

            http://linuxfr.org/~mammique/17910.html(...)

            extrait du svnbook


            Merging changes sounds simple enough, but in practice it can become a headache. The problem is that if you repeatedly merge changes from one branch to another, you might accidentally merge the same change twice. When this happens, sometimes things will work fine. When patching a file, Subversion typically notices if the file already has the change, and does nothing. But if the already-existing change has been modified in any way, you'll get a conflict.


            Ideally, your version control system should prevent the double-application of changes to a branch. It should automatically remember which changes a branch has already received, and be able to list them for you. It should use this information to help automate merges as much as possible.

            Unfortunately, Subversion is not such a system. Like CVS, Subversion does not yet record any information about merge operations
            . When you commit local modifications, the repository has no idea whether those changes came from running svn merge, or from just hand-editing the files.

            What does this mean to you, the user? It means that until the day Subversion grows this feature, you'll have to track merge information yourself. The best place to do this is in the commit log-message. As demonstrated in the earlier example, it's recommended that your log-message mention a specific revision number (or range of revisions) that are being merged into your branch. Later on, you can run svn log to review which changes your branch already contains. This will allow you to carefully construct a subsequent svn merge command that won't be redundant with previously ported changes.


            http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-3.3.(...)
            • [^] # Re: Subversion vs GIT

              Posté par (page perso) . Évalué à 2.

              > Subversion does not yet record any information about merge

              C'est ce qu'il me semblait en fait. C'est d'ailleurs un des ajouts de svk par rapport a subversion. (GNU arch garde aussi l'historique des merge)
  • # Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) ...

    Posté par (page perso) . Évalué à 10.

    Je peux vous garantir qu'une fois qu'on a utilisé SubVersion, CVS ressemble à un dinosaure, et on se demande pourquoi on utilise encore cet outil *désuet* à l'heure actuelle !!! Ce qui change :

    — On peut charger uniquement une partie du dépôt et bosser dessus (dans CVS, ça se passe par "module")

    — On n'a pas besoin de se connecter au serveur pour faire un ajout ou une suppression (chose que je n'ai jamais comprise dans CVS) : ceci rend la préparation d'un commit beaucoup plus agréable

    — Un diff par rapport à la dernière version commitée se fait sans se connecter au serveur (chose magnifique), de même pour avoir avec "status" de répertoire local (ça fait tout bizzare au début de ne pas avoir à attendre 5 min ;-)). De plus "status" est très bien présenté (affiche juste les fichiers qui ne sont pas dans le dépot, les fichiers ajoutés / supprimés, et les fichiers modifiés) : juste comme il faut

    — Un commit SVN est moins bavard qu'un CVS qui remplit l'écran de plein de griboulli

    — On peut créer un répertoire avec SVN (remplace un mkdir X; cvs add X; => lourd à cause de la connexion au serveur pour rappel)

    — Il existe une fonction "magique" (quand on vient du monde CVS) : svn revert qui permet de revenir à la dernière version commitée

    — Un update ajoute automatiquement les nouveaux fichiers (pas besoin d'ajouter -A à la commande)

    — Le répertoire utilisés par SVN sont nommés ".svn", et sont donc cachés. Ceci est plus sympa que les répertoires CVS trop visibles à mon goût.

    — La création de branche est plus pratique, il suffit de dupliquer un répertoire autre part, et hop, on a une branche ...

    — Les numéros de versions (de commit) sont simplement incrémentés (1, 2, ...). C'est plus simple que des 1.1.1, 1.2.34, 1.54, ... (bon ok, c'est discutable, et je crois bien que CVS est plus souple à ce niveau là)

    — Avec l'interface web (CvsWeb, qui comme son nom ne l'indique pas, sait aussi afficher du SubVersion) on peut voir l'ensemble des modifications d'un commit. Chose que je n'ai jamais réussi à faire avec CVS (peut-être avec un cvs history <options magiques> ?).

    — Et puis il y a sûrement plein d'autres avantages. Pour rappel, SVN a été écrit car CVS a été mal pensé niveau sécurité (voir des sites de sécurité et compter le nombre de failles ...) et pour corriger les défauts de conception de CVS.

    En fait, SVN duplique chaque fichier lors du premier "checkout", c'est pourquoi diff/status est si rapide (et revert possible).

    J'ai jamais passé de dépôt CVS en SubVersion, mais il parait que ça se fait bien. Pour info, http://developer.berlios.de/(...) permet d'avoir un dépôt CVS et/ou SubVersion. C'est un des seuls à ma connaissance.

    Pour voir à quoi ressemble à CvsWeb de SVN (y'a un p'tit bug UTF-8 par contre, peut-être parce que je suis en UTF-8 et pas le serveur) :
    http://svn.berlios.de/viewcvs/happyboom/trunk/(...)

    Pour info, HappyBoom est mon projet de réécriture de Wormux en Python et SDL, qui est aujourd'hui un projet expérimental de moteur réseau avec un système multi-agents.

    @+ Haypo étonné de tartiner tellement sur cet outil ;-)
    • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

      Posté par (page perso) . Évalué à 10.

      Je crois que tu as oublié the killer-feature (vis à vis de CVS) : on peut déplacer un dossier ou renommer un fichier.
      • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

        Posté par (page perso) . Évalué à 1.

        tu as oublié facilement parceque avec CVS, tu peux directement déplacer les fichiers du repository (mv tonfichier.c,v etc...) mais apres faut resynchroniser les clients (et croiser les doigts)
      • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

        Posté par . Évalué à 3.

        Est-ce qu'en renomant un fichier il garde une trace de l'historique oubien c'est juste un racourcis pour un cp rm add (ce qu'il me semble avoir entendu dire) ?

        Par exemple, si toto fait une modif sur le fichier X, titi renome X en Y, toto commit sa modif de X, que ce passe-t'il ?

        Et est-il possible par la suite de savoir que Y s'apellait X dans les versions précédentes ?

        par ex (avec bazaar-ng)

        $bzr init
        $echo "je suis X" > x
        $bzr add x
        $bzr commit -m "add x"
        $bzr rename x y
        $bzr commit -m "rename x y"
        $echo "je suis Y" > y
        $bzr commit -m "modif y"
        $bzr diff -r 1 y
        *** renamed file 'x' => 'y'
        --- x
        +++ y
        @@ -1,1 +1,1 @@
        -je suis X
        +je suis Y
        • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

          Posté par . Évalué à 2.

          Est-ce qu'en renomant un fichier il garde une trace de l'historique ou bien c'est juste un racourcis pour un cp rm add (ce qu'il me semble avoir entendu dire) ?


          L'historique est gardé, avec une trace de l'ancien nom, de manière transparente.

          Exemple concret:
          svn log -v client.pl
          [le log de la version 51 a 55]
          A /othello/gui/client.pl (from /othello/gui/main.pl:51)
          [log de la version 1 a 51]

          Le fichier client.pl s'appellait main.pl, et a été renommé (avec svn mv)
          à la revision 51.
          L'option -v de log permet de voir ce genre de changement (et d'autres choses)
    • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

      Posté par . Évalué à 3.

      Je suis aussi passé de CVS à Subversion il y a environ 2 ans. A l'époque Subversion dépendait de cette bouse de BerkeleyDB et les dépôts étaient parfois corrompus. Depuis que Subversion a son propre système de stockage (fsfs, très rapide sur du ReiserFS), c'est d'une fiabilité exemplaire.

      Et puis oui, Subversion résoud toutes les absurdités de CVS, que ce soit pour renommer un répertoire, pour ajouter des liens symboliques, pour le "svn revert", pour le coup d'avoir la version précédente en local, etc. Et puis on critique SVN à cause de ses dépendances lorsque l'on souhaite utiliser Webdav. Mais mine de rien c'est super pratique. Au moins le HTTP avec ou sans SSL, ça passe partout, même derrière des firewalls trop paranos. Et le coup de pouvoir monter un répertoire Webdav quand on n'a pas encore le client SVN installé, c'est top.

      Malgré l'arrivée d'OpenCVS, je n'ai vraiment pas envie de revenir à CVS, il a trop de limitations pénibles.
    • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

      Posté par (page perso) . Évalué à 1.

      De nombreux projets ayant basculé sous SubVersion ces derniers mois, j'en ai déduit que cet outil était arrivé à matûrité et j'ai donc décidé de l'essayer à mon tour.

      La première impression est très positive mais :

      * Bien qu'annoncé comme le fils spirituel de CVS, Subversion requiert un certain temps d'adaptation car certains aspects sont traités de manière très novatrice pour un adepte de CVS.

      * Subversion peut stocker les fichiers dans une base Berkeley DB ou dans son propre « système de fichiers », FSFS. L'expérience m'a montré que les droits d'accès sont problématiques avec une base Berkeley DB dans un contexte multi-utilisateur. D'ailleurs, dans le livre « Version Control with Subversion », il est conseillé d'utiliser dans ce cas un espace de stockage de type FSFS.

      * Les répertoires administratifs .svn contiennent deux copies de chaque fichier importé dans le référentiel. Cela permet d'effectuer des diffs et d'autres opérations en local et présente de sérieux avantages. En contrepartie, la copie de travail du projet s'avère donc 3 fois plus volumineuse que les sources originelles. Quelqu'un a dit que le projet KDE représentait 15 Go de sources. Pour importer une copie de travail intégrale du projet, il faut donc prévoir 45 Go d'espace disque !

      Mais une fois ces problèmes assimilés, il est vrai que Subversion a de nombreux atouts pour séduire, à commencer, pour moi, par les commits atomiques, la gestion des répertoires, le renommage et le déplacement de fichiers sans perte de l'historique.

      Sébastien
    • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

      Posté par (page perso) . Évalué à 6.

      Et puis il y a sûrement plein d'autres avantages.

      Oui, et à mon avis tu as oublié le plus important de tous : l'atomicité des commits. Pour moi, c'est ça la "killer-feature" de Subversion par rapport à CVS.

      Sous CVS, les commits sont gérés fichier par fichier. Les numéros de version sont indépendants fichier par fichier. Et lorsqu'on fait des merges entre branches sur un module complet, faut s'accrocher. Par exemple il faut bien du courage pour faire un merge entre une branche A et une branche B à partir d'autre chose que les dernières versions des fichiers sur la branche mergée. (tout simplement parce qu'on ne peut pas faire à la fois -r <ma_branche> et -D <ma date>) La solution que j'emploie est un peu batarde, limite lourdingue : mettre des tags sur l'intégralité des mes modules sur les niveaux des commits que je suis susceptible de vouloir merger plus tard :-/

      Sous SVN, tranquille, j'ai un numéro de version à merger, je le connais, il est unique : les numéros de version, en plus d'être simplifiés car sous forme d'entier incrémenté, sont propre au dépôt complet.
      • [^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .

        Posté par (page perso) . Évalué à 3.

        Arf oui, j'ai oublié la possibilité de renommer (c'était trop évident, c'est pour ça que je l'ai oublié ;-)) et les commit atomiques. Ayant pas mal utilisé CVS (dont deux fusions de branches), je peux dire que lorsqu'un commit foire ... C'est un gros paquet d'emmerdes *garantis*. Exemples concrets : connexion Wifi qui tombe (une mouche a pété, j'ai perdu un paquet, pouf) ou alors le serveur qui coupe la connexion durant un GROS commit.

        Haypo
  • # KDE 4

    Posté par (page perso) . Évalué à 4.

    Je sais que ca n'a pas trop de rapport mais je me posse quelques questions.
    Je ne suis pas sous linux deppuis assez longtemp pour connaitre les rythmes de sorties des versions de KDE ni meme si les avancés entre un KDE 3 et un KDE 4 sont enormes. Donc en gros je me demande :

    - a quand le prochain KDE? 3.5 ou 4? les sorties sont a dates fixes? ou simplement quand les developpeurs considérent qu'une sortie serait de bon tons?

    - a quels nouveautés peut on s'attendre dans KDE 4? j'ai lu ceci : http://aseigo.bddf.ca/?pID=1221(...) j'en ai appris pas mal malgré mon anglais. Mais ca ne dit pas vraiment grand chose sur le "eye candy".

    en gros a quoi peut on s'attendre pour KDE4? et a t'on unee idée de quand il devrait sortir?
    • [^] # Re: KDE 4

      Posté par . Évalué à 3.

      Pour que KDE4 sorte il va d'abord faloir que QT4 sorte.
      Je pense que l'on verra un KDE 3.5 contenant un lot de bug fix avant
      • [^] # Re: KDE 4

        Posté par . Évalué à 5.

        J'ai cru voir passer un Juin-2006 pour KDE4 et Septembre/Octobre-2005 pour KDE 3.5.

        Mais les dates ne sont pas encore fixées, même si c'est sur qu'il va falloir attendre que Qt4 se stabilise pour pouvoir sereinement baser une release de KDE dessus.
        Cependant, le développement pour KDE4 a débuté : wouhou ! (Cf blog d'Aaron Seigon).
        En effet, kdelibs a été compilé avec Qt4 : c'est le commencement du début.

        Par contre je n'ai trouvé aucun tag ni aucune branche KDE4-dev ou quoi que ce soit d'approchant sur le SVN de KDE...
        • [^] # Re: KDE 4

          Posté par (page perso) . Évalué à 10.

          c'est ici : http://websvn.kde.org/home/kde/branches/work/kde4/

          le boulot a commence mais non, kdelibs ne compile pas entierement ;)

          DCOP a ete porte et devrait meme etre compat avec le DCOP de kde3.x.
          Reste a faire des tests reels pour voir ce que ca donne.

          kdecore, on a presque fini, encore quelques portages a faire. Peut-etre ce soir, si j'ai le temps j'essaierai de tout finir (y a des subtilites a travailler tout de meme, et je ne parle que de "faire compiler" la bete ...) (de la a ce qu'on puisse lancer une KApplication, y aura sans doute encore un pas ;)

          kdeui, alors la c'est pas pour demain, plein de changements a faire ;)
          kio, devrait a priori pas etre trop complique d'apres ce que j'ai pu en voir...

          le reste de kdelibs devrait suivre sans trop de problemes normalement

          Maksim a deja porte kdefx ainsi qu'un style de base pour les fenetres, il va attaquer keramik il me semble.
          Thiago s'est occupe de la couche reseau qu'il avait prepare depuis un moment.

          apres il faudra voir pour kdebase ou y aura un boulot enorme egalement.
          une fois qu'on aura tout ca, qu'on aura bien compris toutes les subtilites, y a moyen que ca aille un peu plus vite pour le reste des applis.

          bref, pour voir demarrer un kde4 (encore faudrait-il en avoir envie hein parce que pour le moment ... ;), il faudra compter plusieurs semaines ;)

          Mik
    • [^] # Re: KDE 4

      Posté par . Évalué à 6.

      J'en connais aps beaucoup plus que toi mais....

      KDE 4 est dépendant de la sortie de QT4. Et du fait d'une sortie non fixée de QT4, la date de sortie de KDE 4 ne peut être fixée elle-même.

      A l'origine, il me demble que KDE 3.4 n'était pas prévue car ils devaient passer directement à la version 4 mais QT 4 se fait attendre donc une version 3.5 vera surement le jour.

      Pour KDE 4, les developpeur devront se familiariser avec les nouvelles API et le developpement de la branche 4 ne peut commencer car des changements fondamentaux en dépendent.

      Pour les apports de KDE 4, on devrait s'attendre à une plus grande rapidité (car QT4 est annoncé plus rapide), l'abandont de arts et l'integration d'un des (je sais pas comment on dit) "gestionnaire de son". Il a pas été encore choisi (gstreamer,et d'autres ...)

      Voilà, t'en sais autant que moi ;)
      • [^] # Re: KDE 4

        Posté par (page perso) . Évalué à 3.

        bah merci en gros tu repond a pas mal de mes questions.

        pour les nouvveautés de KDE4 j'ai vu qu'apparemment ils bossent actuellemennt sur un systéme d'indexation du disque dur permettant de faire des recherches rapide et plus pertinente a la WinFS apparemment.

        Et pour le son ben jsuis bien content parce que j'ai souvent des problémes de son.

        Sinon bah pour le moinssage je comprend pas trop! le hors sujet peut etre.
      • [^] # Re: KDE 4

        Posté par . Évalué à 2.

        QT 4 devrait sortir cet été.

        Certains développeurs KDE ont déjà commencé à porter des petits bouts de KDE sur QT4 avec la version en développement.

        Pour le moteur de sons, il est normalement prévu de laisser le choix à l'utilisateur/distrib, y'aura une couche d'abstraction qui s'appellera kdemm.
    • [^] # Re: KDE 4

      Posté par (page perso) . Évalué à 3.

      La dernière roadmap (mais ça change régulièrement, donc ça peut encore changer) est la suivante :
      Pour les librairies de base de KDE, les développeurs ont déjà commencé à intégrer QT4 (avec la dernière version beta) depuis quelques jours. Donc le boulot a commencé, mais ce sera pas fini avant... pfiou, longtemps.
      En attendant, pour ne pas rester pendant plus d'un an sans release, ils ont prévu un KDE3.5 qui ne touchera pas aux libs de base mais qui permettra aux développeurs d'applications KDE de continuer à ajouter des features.
  • # De l'espoir...

    Posté par (page perso) . Évalué à 3.

    Peut être a-t-on une chance de voir arriver l'intégration d'outils subversion dans KDE (comme le fait cervisia pour CVS) maintenant que les développeurs de KDE seront ammenés à emlployer Subversion courament !?

    Personnellement, j'attends encore un outils proche de ce que fait TortoiseSVN sous Windows pour mes deux desktop préférés (KDE & Gnome)... Mais, j'ai appris à être patient !

    (Ceci dit peut être ai-je raté un projet existant sur le sujet ?)
  • # Details de la migration

    Posté par . Évalué à 3.

    Y a-t-il un endroit où un gars de KDE aurait recensé tous les problèmes, astuces et autres incantations vaudoues qu'ils ont du accomplir pour réaliser leur migration ? (Éplucher les mailing-listes ne m'emballe pas des masses, mais s'il faut en passer par là)

    Une migration de cette taille ne s'est sûrement pas passée sans heurts (1 mois de décalage entre la lettre d'intention (1 Avril) et la date effective) et j'aurais donc voulu avoir accès à cette expertise...

    PS: mon ami google me donne juste des pointeurs vers comment se servir de SVN pour les commits de KDE...
  • # Quid de GNU Arch?

    Posté par . Évalué à 1.

    Bonjour tout le monde,

    que pensez-vous du prometteur GNU Arch? Il est utilisé je crois pour le développement de la Ubuntu.

    Extrait du manuel francisé http://flibuste.net/libre/tlafr/(...) :
    Arch ne repose pas sur une « distribution centralisée ». Par exemple, il n'est pas indispensable de donner un accès en écriture à tous les contributeurs importants d'un projet. Au lieu de cela, chaque contributeur peut avoir sa propre archive pour son travail. Arch opère en souplesse parmi les liens entre les archives.


    Cette distribution des sources et des droits de modification me semble très prometteuse, notamment pour le monde du logiciel libre. Participer, collaborer, forker, ou réutiliser une ou plusieurs archives deviens pratique courante. La production coopérative confortable :) Est-ce simplement un manque de visibilité de GNU Arch dû à sa jeunesse qui vous fait préférer SubVersion? Ou bien voyez-vous dans cette distribution des archives une fausse bonne idée difficilement applicable actuellement?

    Bref, je pense qu'un retour d'expérience ou un simple avis sur la question pourrait intéresser du monde :)
    • [^] # Re: Quid de GNU Arch?

      Posté par (page perso) . Évalué à 0.

      >> Bref, je pense qu'un retour d'expérience ou un simple avis sur la question pourrait intéresser du monde :)

      je n'ai pas un avis d'expert mais d'après ce qu'on peut lire sur internet il semble que la syntaxe des commandes d'arch soit vraiment pourrie jusqu'au trognon.
      le concept de gestionnaire de code distribué est bon et il existe beaucoup d'alternatives : je crois que Bazaar reprends le meilleur d'arch en essayant de corriger les erreurs....et maintenant y'a bazaar-NG (developpé par ubuntu) et qui doit être LE TRUC ULTIME en matière de gestionnaire décentralisé.
    • [^] # Re: Quid de GNU Arch?

      Posté par (page perso) . Évalué à 3.

      Un probleme avec arch c'est qu'il n'y a pas de client pour windows (meme pas avec cygwin), ceci etant du aux noms de fichiers bizarroides qu'arch utilise pour faire son boulot.
      • [^] # Re: Quid de GNU Arch?

        Posté par . Évalué à 5.

        Une version cygwin existe maintenant.

        Arch à la qualité et le gros défaut d'utiliser des concepts que ne font pas partie des habitudes collectives.

        Arch ne s'utilise pas du tout comme CVS, subversion à des similitudes, et un soucis pour faciliter la transition (on passe d'un système centralisé à un système décentralisé, ça n'aide pas)

        Le gros des critiques sur Arch, plus que la syntaxe (moi je l'aime bien), c'est l'auteur Tom LORD que beaucoup critique au niveau de ses choix.

        Arch est tellement différent qu'il fait peur. Moi j'ai commencé par Arch et ne connait pas le reste donc ce fut facile pour moi, je ne sais pas ce à quoi ressemble CVS ou subversion, mais arch je l'utilise professionnellement et avec beaucoup de plaisir.

        Arch c'est la déroute, mais c'est cool !!

        • [^] # Re: Quid de GNU Arch?

          Posté par (page perso) . Évalué à 6.

          > Tom LORD que beaucoup critique au niveau de ses choix.

          Disons que Tom a un certain nombre de gros défauts:

          * Il aime bien commencer les choses, pas les terminer. Ceux qui suivent la mailing list de arch ont vu passer pas mal de projets (XL, support de git, réécriture complete pour la version 2, bugtracker ...), mais pas grand chose de concret.

          * Il a un complexe de supériorité. « C'est comme ça que je fais, donc, c'est la bonne façon ». Ben non, c'est pas parce que lui, aime mettre des accolades dans les noms de fichiers que moi j'aime ça aussi ...

          * Il aime réinventer la roue. Il a réinventé la manipulation des chaines de caractères, la gestion de la mémoire en C, les autotools, la programmation orientée objet, ... J'aurais préféré qu'il passe ce temps sur des choses utiles.

          * Il ne supporte pas de déléguer. Réguliérement, quelqu'un tente de reprendre le développement de Arch (jblack, jivera), mais à chaque fois, le mec abandonne ou se fait virer au moment de la release candidate, et on jette son travail.

          bazaar est un fork de tla fait par les gens de canonical, qui s'est affranchi un peu de tout ça. Y'a de l'espoir ...

          --
          Maybe I'm simply a more effective Unix user than many people. So, [...]
          -- Tom lord, 18 Oct 2004.
      • [^] # Re: Quid de GNU Arch?

        Posté par (page perso) . Évalué à 2.

        Non, c'est surtout du au fait que les systèmes de fichier disponibles sous Windows sont très limités: longueur maximum d'un patch très limité, pas d'informations fiables pour les inodes, pas de liens hard, et d'autres petits détails que l'on trouve sur les systèmes compatibles POSIX.

        (Mais je ne cherche pas à justifier le nommage des fichiers spécifiques à arch ;)
        • [^] # Re: Quid de GNU Arch?

          Posté par (page perso) . Évalué à 4.

          Pour ceux qui n'auraient pas suivi, j'ai par exemple un fichier

          thelove@canonical.com/bazaar-debian/bazaar-debian--debian/bazaar-debian--debian--1.4/bazaar-debian--debian--1.4--base-0/\{arch}/bazaar-debian/bazaar-debian--debian/bazaar-debian--debian--1.4/thelove@canonical.com/patch-log/base-0

          sur ma machine (a l'intérieur d'un répertoire que j'ai choisi). Evidemment, sur un système de fichiers ou le chemin complet est limité a 256 caractères, on touche vite les limites.
          • [^] # Re: Quid de GNU Arch?

            Posté par . Évalué à 3.

            Et au passage ça révèle aussi un autre bug:

            - soit dans l'interpreteur css de mozilla-firefox
            - soit dans le code de linuxfr

            Parceque le nom du fichier dépasse très largement du cadre chez moi.
            • [^] # Re: Quid de GNU Arch?

              Posté par (page perso) . Évalué à 2.

              C'est normal. Firefox ou n'importe quel autre navigateur n'a pas de moyen de couper, il n'y a aucun espace. Linuxfr apparamment ne coupe pas, donc.

              On pourrait eventuellement planquer ce qui dépasse en CSS. La, le choix de l'auteur de la CSS, si il a pensé a ce cas, c'est de laisser dépasser pour tout voir.
          • [^] # Re: Quid de GNU Arch?

            Posté par . Évalué à 2.

            thelove@canonical.com/bazaar-debian/bazaar-debian- [..mega-longue-chaîne coupée..]

            Evite STP de mettre des chaîne de caractères super longues, ça tue la mise en page, en particulier à l'impression (avec l'option "fit width" on se retrouve avec une police de taille genre 4, dur à lire).
            Rajoute un espace (ou plus) pour permettre le "wrapping".
    • [^] # Re: Quid de GNU Arch?

      Posté par . Évalué à 1.

      arch est vraiment très performant et pleins de fonctionalités, largement plus que subversion, (on peut aussi faire du centralisé avec).

      Le problème c'est que du fait qu'il est décentralisé il devrait être beaucoup plus simple à installer (pas de serveur par ex) et utiliser que subversion, hors c'est tout l'inverse, de fait il est inaccessible aux débutants, aux utilisateurs de windows etc... Et comme l'auteur est une sorte de génie qui nous déverse de très long discours théoriques (invention d'un nouveau langage, d'un wiki...) la plupart des contributeurs l'ont laissé tomber pour d'autres horizons plus accessibles.

      Mais le principe reste extrèmement intéressant à mon goût et mérite d'être essayé.

      Dès que possible je mettrai en parralelle le tutorial de gnuarch (un peu périmé) et celui de bazaar-ng, ça permettra de cerner rapidement les avantages et inconvénients de chacuns.

      Comme tout ça est libre, il y a de plus en plus de passerelles pour aller de l'un à l'autre, aucun problème donc pour démarrer avec l'un et passer à l'autre au besoin.
    • [^] # Re: Quid de GNU Arch?

      Posté par . Évalué à 2.

      un logiciel selon qu'il est centralisé ou pas induit des normes de développement, donc si tu commences à travailler en centralisé, il est logique de continuer avec un outils spécialisé dans le centralisé.

      Même si je suis un pro Arch à fond, certaines fonctionnalités sous subversion n'existe pas sous Arch (et inversement), donc même si Arch peut centraliser les dépôts, il induit trop de changement dans les normes de développement.

      Tu as essayé le dernier Arch 1.3.2, il est terrible, la série 1.3 remanie la cohérence des commandes, ça devient très sympas !
      • [^] # Re: Quid de GNU Arch?

        Posté par (page perso) . Évalué à 3.

        > Tu as essayé le dernier Arch 1.3.2, il est terrible

        Disons qu'il y a quelques unes des nouveautés de bazaar que Tom s'est décidé a merger. Il reste encore beaucoup a bazaar (cache, archive registry, annotate, ...).
        • [^] # Re: Quid de GNU Arch?

          Posté par . Évalué à 3.

          Sympa la feature request pour l'historique des patchs ayant modifié un fichier.
  • # Les grands esprits se rencontrent ?

    Posté par . Évalué à 5.

    Les gars de Gnome ont l'air d'envisager eux aussi une migration sous subversion (ou Bazaar), cf le blog de James Henstridge:
    http://www.advogato.org/person/jamesh/diary.html?start=196(...)

    Si j'en crois ce message, ils veulent faire "comme KDE" ;) (c'est juste un petit troll, j'ai pas pu résister)
    http://mail.gnome.org/archives/gnome-hackers/2005-May/msg00001.html(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.