Centralisé et Décentralisé

• [^]Re: Centralisé et Décentralisé

  Posté par ribwund () le 21/06/2008 à 12:13. (lien). Évalué à 4.

  On a pas deja eu 10.000 threads (trolls?) dessus ? A mon avis tu google, tu cherche les anciennes depeches sur git/mercurial/bzr/darcs et tu trouveras ce que tu cherche.

• [^]Re: Centralisé et Décentralisé

  Posté par Nÿco (Jabber id, page perso, ) le 21/06/2008 à 12:26. (lien). Évalué à 4.

  Y'a du gros boulot à faire sur ces articles, mais ça peut t'aider :
  http://en.wikipedia.org/wiki/Version_control_system
  http://en.wikipedia.org/wiki/Distributed_revision_control
  http://en.wikipedia.org/wiki/Comparison_of_revision_control_(...)

  --
  Jabber ID : xmpp:Nyco@jabber.fr

• [^]Re: Centralisé et Décentralisé

  Posté par baud123 (Jabber id, page perso, ) le 21/06/2008 à 13:04. (lien). Évalué à 8.

  Tu peux te poser les questions suivantes :
  - suis-je toujours connecté à Internet ?
  - des commits réguliers permettent-ils d'avoir un meilleur suivi du changelog par fonctionnalité implémentée ?
  - de plus petits commits facilitent-ils la gestion des conflits d'édition ?
  - release-early/release often fonctionne-t-il bien en décentralisé ?
  - combien de contributeurs travaillent sur des fonctionnalités décorrélées ?
  - à quelle cadence est-il nécessaire d'avoir une version rassemblant toutes les contributions en cours ?
  - quel est le plus simple pour les utilisateurs du dépôt pour avoir une version homogène ayant le plus de fonctionnalités ?

• [^]Re: Centralisé et Décentralisé

  Posté par Florent Zara (Jabber id, page perso, ) le 21/06/2008 à 13:22. (lien). Évalué à 4.

  Si tu veux des avis subjectifs, tu as celui de Linus qui a créé Git (décentralisé). Il s'agit d'une conférence qu'il a donné chez Google :
  http://video.google.com/videoplay?docid=-2199332044603874737
  Tu as aussi un avis sur cette conférence ici : http://thomas.enix.org/Blog-20070805231406-Technologie&s(...)
  
  Et concernant les journaux, voici un autre point de vu, principalement sur les décentralisés là aussi :
  https://linuxfr.org/~NoNo/26146.html
  https://linuxfr.org/~NoNo/26309.html

• [^]Re: Centralisé et Décentralisé

  Posté par Misc (page perso, ) le 21/06/2008 à 14:46. (lien). Évalué à 10.

  Je sais pas si ça peut t'aider, mais la conférence sur mercurial des journées pythons francophones de cette année peut t'éclairer https://linuxfr.org//2008/06/03/24172.html ( J'ai fait la conférence ).
  
  Je te conseille la lecture du livre sur bzr ( http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html ) la partie sur les workflows, de voir les conférences sur git, etc, sur google video.
  
  En tapant git vs svn, bzr vs darcs, etc sur un moteur de recherches, tu peut aussi trouver de nombreux articles sur ça.
  
  En général, ce qui va en ressortir, c'est que git est complexe, que bzr est simple, que hg et git sont rapides, et que beaucoup de gens vont dire que les vcs centralisés, c'est pourri ( ce qui à mon sens n'est pas vrai ).
  
  Il faut bien voir que c'est avant tout une question de processus de travail, et d'outils. Il y a pas de raison de changer ce qui marche, donc, avant d'envisager une migration, il faut savoir pourquoi.
  
  La plupart des dvcs ne sont pas optimaux pour des projets avec des gros fichiers dans l'historiques, car cela consomme une place conséquente. De même, l'intégration des outils avec svn est en général mature, alors que pour la plupart des systèmes récents, c'est pas encore ça ( je pense notamment à des outils proprios, comme xcode, visual c++, mais aussi des applications libres comme trac ( même si ça a récemment changé pour trac ) ou review board ( http://www.review-board.org/ ) )
  
  Il faut également prendre en compte les gens de ton équipe ( si il y en a ), qui peuvent avoir autre chose à faire que d'apprendre un nouveau systéme. Et il y a également un facteur à prendre en compte, c'est que personne ne conteste la prédominance de svn dans le monde des vcs centralisés, mais par contre, dans le monde des dvcs, le consensus n'est pas la, ( exemple : http://lists.freebsd.org/pipermail/freebsd-current/2008-June(...) )
  
  Pour ma part, j'ai l'impression que beaucoup de gens qui migrent, migrent vers git, aussi bien de svn, que de systèmes comme mercurial ( exemple, alsa ) que monotone ( exemple, openmoko ).
  
  Parmi les gros utilisateurs de mercurial, on peut trouver sun ( qui se standardise sur mercurial ( http://opensolaris.org/os/community/tools/scm/ ), xen, et d'autres.
  La page de sun explique bien les divers problématiques et les raisons de leur choix.
  
  Pour bzr, j'ai par contre l'impression que ça tient plus du choix philosophique. Emacs migre parce rms a dit "faut utiliser un projet gnu" ( http://lwn.net/Articles/272853/ ), mysql migre pour avoir un système plus libre que bk , et parce que canonical a corrigé les problèmes pour mysql, ( http://blogs.mysql.com/kaj/2008/06/19/version-control-thanks(...) ).
  
  Donc, c'est une question ouverte, un troll multi niveau qui a de l'avenir, pour remplacer les traditionnels "java ça pues, suse c'est pas libre, et flash c'est nul". Surtout que les dvcs bougent trés vite, copiant les fonctionnalités de l'un à l'autre à tout bout de champ ( exemple, git-svn repris par bzr, git ayant repris et amélioré le commit interactif de darcs ), ou en rajoutant certaines très intéressante ( http://blog.madism.org/index.php/2007/09/09/138-git-awsome-n(...) , http://kerneltrap.org/node/11753 )

  • [^]Re: Centralisé et Décentralisé

    Posté par vincent_k (Jabber id, page perso, ) le 21/06/2008 à 17:06. (lien). Évalué à 2.

    En voilà un commentaire qui m'aide (un peu :) )
    Je n'ai aucun à priori sur la supériorité de tel ou tel système, j'ai juste testé Subversion en local et j'avais trouvé ça marrant. Et vu que je ne suis pas encore dévellopeur, je ne peux pas dire si telle ou telle feature est intéressante où pas.
    Faudrait que je teste Git et Bazaar, mais ça va être difficile de comparé quand on a pas de travail à mettre en commun :p

  • [^]Re: Centralisé et Décentralisé

    Posté par Victor STINNER (Jabber id, page perso, ) le 23/06/2008 à 11:36. (lien). Évalué à 5.

    misc m'a convaincu de tester Mercurial. En fait, la semaine où j'ai lancé mon projet Hasard, j'errais entre le train et l'hôtel, deux lieux généralement dépourvus d'Internet (gratuit). En gros, il suffit de remplacer "svn" par "hg" dans la ligne de commande. Pour publier son travail (et faire une sauvegarde), il faut faire "hg push" de tant à autre. Mercurial marche très bien avec Apache et SSH. Quand on veut récupérer les modifications des autres, "hg pull" ne suffit pas. Il faut aussi faire "hg update" et "hg merge", chose assez déroutante quand on vient de Subversion.
    
    Quelques remarques personnelles sur svn VS hg :
    - je commite très souvent car c'est instantané (c'est un peu comme passer de cvs diff à svn diff !) et ça coûte pas cher. Je dois faire 4 à 10x plus de commits, qui sont donc plus petits, plus facile à relire, et c'est aussi plus facile à annuler.
    - on peut supprimer ses derniers commits avec "hg strip", là où subversion est totalement figé : interdiction absolue de supprimer du code (même si on a commité /etc/shadow ou des photos perso)
    - mis à part hg push et hg pull, toutes les opérations sont instantanées, ça fait limite peur au début :-)
    - hg push envoie N commits d'un coup alors que svn ci n'envoie qu'un commit
    - hg revert conserve une copie du fichier modifié (c'est optionnel : hg revert --no-backup)
    - hg ci quitte si le changelog est vide (c'est très positif :-))
    - j'ai merdé : j'ai mis plusieurs dizaines de mégaoctets de fichiers de test dans mon dépôt par erreur. Du coup, le dépôt pèse 40 Mo alors que les sources font juste 40 Ko (en virant l'historique avec "rm -rf .hg*"). Je pense qu'avec l'expérience, je ne ferai plus cette erreur (ex: "hg strip" pour virer des commits).

    • [^]Re: Centralisé et Décentralisé

      Posté par Jean-Philippe (page perso, ) le 27/06/2008 à 17:27. (lien). Évalué à 1.

      Merci pour ce commentaire très sympa, j'ai bien envie de me mettre à un dvcs mais bazaar ne me motive pas et git a l'air hype mais vraiment over compliqué (je cherche plutot comme dit ici un svn ou on peut commit en local)
      
      2 petites questions sur mercurial :
      - est-ce qu'on peut merger des commits locaux avant de "pusher" les changements ? (par exemple j'ai 5 commits sur ma tache A et 4 sur ma tache B, je veut envoyer 2 commits pour la tache A et B, de manière propre)
      - est-ce qu'on a des dossiers .hg partout, comme svn, ou c'est propre comme git ? :)

      • [^]Re: Centralisé et Décentralisé

        Posté par Victor STINNER (Jabber id, page perso, ) le 30/06/2008 à 10:39. (lien). Évalué à 2.

        - est-ce qu'on peut merger des commits locaux avant de "pusher" les changements ?
        
        Ah, ça je sais pas. Je suppose que oui. Selon un ami, cette extension (incluse de base) devrait faire l'affaire :
        http://www.selenic.com/mercurial/wiki/index.cgi/TransplantEx(...)
        
        est-ce qu'on a des dossiers .hg partout, comme svn, ou c'est propre comme git ? :)
        
        À la racine, il y a un dossier ".hg" qui contient 99% des infos. Sinon, il existe .hgignore qui contient les listes des fichiers à ignorer pour la commande "hg stat" (la syntaxe est sex : on peut mélanger les motifs "glob" et motifs "regex"). Enfin, j'ai un fichier ".hgtags" qui contient les tags. Je ne sais pas pourquoi ce fichier n'est pas dans .hg !? RTFM disait Mao.

• [^]Re: Centralisé et Décentralisé

  Posté par zero heure (Jabber id, page perso, ) le 22/06/2008 à 13:51. (lien). Évalué à 3.

  D'après les développeurs de Subversion (cf le lien "Subversion’s Future"):
  Les systèmes de gestion décentralisés sont l'avenir pour beaucoup de projets, en particulier les projets libres, cependant qu'un système centralisé conserve tout son intérêt pour des projets d'entreprise. Ce qui se conçoit aisément. Ils notent d'ailleurs la croissance vertigineuse du nombre d'adoptions de Subversion en entreprise. Enfin, Subversion sera vraisemblablement le dernier centralisé développé en libre (c'est la fin d'un modèle).

  --
  J'ai vu bien des choses dans ma petite vie, et je mesure amèrement l'impuissance à les dire. (JP Rosnay, Le 13ème apôtre) http://www.poesie.net/apotre2.htm

  • [^]Re: Centralisé et Décentralisé

    Posté par taz008 () le 23/06/2008 à 09:24. (lien). Évalué à 4.

    Je parlerais plutôt d'un aboutissement que d'une fin. Il est toujours activement développé, et comme indiqué dans l'article "Subversion's future", le nombre de projets l'utilisant augmente toujours.

  • [^]Re: Centralisé et Décentralisé

    Posté par Antoine () le 27/06/2008 à 23:14. (lien). Évalué à 2.

    Enfin, Subversion sera vraisemblablement le dernier centralisé développé en libre (c'est la fin d'un modèle).
    
    Surtout qu'il est trivial d'utilisé un système décentralisé de façon centralisée. Qui peut le plus peut le moins.

• [^]Re: Centralisé et Décentralisé

  Posté par wilk (Jabber id, page perso, ) le 23/06/2008 à 18:32. (lien). Évalué à 1.

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

revno: 1233
date ...
message :

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


  etc. Donc chaque étape regroupant plusieurs commits dans une branche à part reste bien visible. Une étape peut également montrer une autre étape s'il y a un merge entre deux branches (indenté d'avantage etc.).
  
  Ensuite, si je souhaite montrer le code à un collègue il y a bien sur tout un tas de possibilité de push pull & co, automatique ou non...

Beurk

Merge

• [^]Re: Merge

  Posté par Raphaël SurcouF (Jabber id, page perso, ) le 21/06/2008 à 15:33. (lien). Évalué à 2.

  As-tu essayé avec SVK ?

• [^]Re: Merge

  Posté par Alban Crequy (Jabber id, page perso, ) le 21/06/2008 à 16:26. (lien). Évalué à 5.

  Tu utilises le "svn merge" de base ou svnmerge.py?
  http://www.orcaware.com/svn/wiki/Svnmerge.py
  
  Avec svnmerge.py, ca marche très bien, à la fois pour tirer une branche de temps en temps et pour le cherry picking. On peut merger dans tous les sens. Les commits d'une branche intégrés dans une autre sont sauvegardés dans la propriété SVN svn-integrated si je me souviens bien, et ça marche tout seul :-)
  
  Faire un diff/patch à la main... heu...
  
  git-svn est pas mal (je l'utilise quand un projet utilise SVN pour directement travailler avec git) mais je ne sais pas s'il s'intégre correctement à svnmerge.py. Si les collaborateurs du projet utilisent svnmerge.py et que d'autres utilisent git-svn, je peur que le suivi des opérations de merge en patisse...

  • [^]Re: Merge

    Posté par cykl (Jabber id, ) le 21/06/2008 à 17:16. (lien). Évalué à 6.

    "svn merge" ne sait merger que des commits sans se souvenir si ils ont déjà été mergé ou non. C'est une commande qui ne devrait pas être destiné à l'utilisateur final.
    
    svnmerge.py on l'a testé pendant un bon moment. Ca marche pas mal pour garder des branches tirées du trunk à jour. Par contre pour merger une branche de devel dans le trunk en fin de développement il est très souvent à l'ouest (sans compter que svnmerge demande pas mal d'itérations pénibles). En gros sur une vingtaine d'intégrations de branche il en a réussi une seule parfaitement. Je ne compte pas les branches ou il y a des déplacement de fichiers, la ca ne peut pas marcher.
    
    Pour le diff/patch à la main pour intégrer une branche, ca va souvent plus vite quand tu vois que svnmerge commence à perdre les pédales si tu n'as pas de solutions de secour.
    
    Pour ce qui est de SVK non je n'ai pas testé. git-svn répond totalement à mon besoin:
    
    1- Les utilisateurs/développeurs lambda peuvent toujours utiliser SVN et tout les outils liés. On ne veut pas d'un VCS distribué.
    
    2- Je travaille quotidiennement avec une dizaine de branches. Avoir 10 working copies est compliqué à gérer . Il doit y avoir bijection working copy <=> projet dans l'IDE. Quand tu créer/ferme des branches plusieurs fois par semaine la manipulation commence à être lourde. C'est aussi consommateur d'espace. 10x377Mo pour SVN contre 1x397Mo pout git-svn !
    
    3- J'ai le confort d'avoir des branches privées si nécessaire. Il est très facile d'exporter une branche privée sur le serveur SVN si un autre développeur à besoin de ma branche.
    
    4- Le mapping branche SVN vers branche git est trivial. Ainsi quand svnmerge.py s'est vautré merger une branche c'est: git co -b SVN_remotebranch remotebranch ; git co master ; git merge SVN_remotebranch. Je n'ai jamais vu git-svn se planter.
    
    Note que je n'utilise pas git et je ne vois pas d'intérêt aux DVCS sauf cas particuliers. Mes critiques contre svn/svnmerge viennent de mon expérience.
    Cette semaine j'ai encore mergé cinq branches vers le trunk, veilles de 2 semaines à 6 mois. Peut être que chez vous ca marche, mais pour moi non. Et dans tout les cas, svnmerge ne peut pas marcher si tu déplaces un fichier.
    
    Bref j'étais pas convaincu il y a six mois. Mais maintenant je checkout directement via git-svn tout les projets.

    • [^]Re: Merge

      Posté par zul (Jabber id, page perso, ) le 22/06/2008 à 01:04. (lien). Évalué à 3.

      Sans vouloir paraphraser Linus Torvalds, personne n'oblige à utiliser git dans un modèle décentralisé. A ma connaissance, il n'y a vraiment que pour le kernel linux ou git est vraiment utilisé dans un tel modèle. La majorité des projets gérés par git (et en premier lieu Xorg), reste un modèle globalement centralisé. git, même en centralisé apporte à mon avis un confort certain (et bien moins de load sur le serveur).
      
      Après, on peut toujours aimer se tortuer l'esprit en passant par git-svn ou git-autretruc jusqu'au jour ou un fait un truc un peu r00t pas forcément prévu.
      
      Enfin, git n'est probablement pas la solution ultime aujourd'hui, même si en tant que VCS, il poutre pas mal la concurrence amha. Il reste le facteur du portage Windows et l'intégration àlaturtoise.

      • [^]Re: Merge

        Posté par Sytoka Modon (page perso, ) le 22/06/2008 à 09:50. (lien). Évalué à 5.

        Il est clair que svn a une excelente intégration dans Windows (Tortoise) ce qui fait que des non informaticiens utilisent le produit avec très peu de formation.
        
        C'est un des soucis aujourd'hui, subversion est bon moyennant ce problème de merge de branche et les autres sont bon aussi moyennant l'aspect multi-plateforme et facilité pour l'utilisateur lambda.
        
        Un de mes objectifs est de fédérer le développement pour des utilisateurs lambda dont une bonne partie est sous Windows, projets qui ont un développeur principal. Donc je suis parti sur quelque chose de simple qui apporte une réelle plus value rapidement : trac + svn.
        
        Il est clair que quelques utilisateurs avancés (dont moi !) arrivent rapidement aux limites de cet environnnement. Mais globalement, j'aurais mis un git en place que seuls ces quelques utilisateurs l'auraient utilisé, et je ne serais pas plus avancé aujourd'hui.

        • [^]Re: Merge

          Posté par ribwund () le 22/06/2008 à 13:49. (lien). Évalué à 3.

          Il me semble que TortoiseHG est relativement bien avancé.
          
          http://tortoisehg.sourceforge.net/

      • [^]Re: Merge

        Posté par cykl (Jabber id, ) le 22/06/2008 à 13:14. (lien). Évalué à 3.

        Une migration de VCS c'est ultra couteux en temps. Là l'avantage c'est qu'on ne change rien pour les devs qui n'ont pas à se soucier des branches. Bref actuellement tout le monde est content de la solution.
        
        Et effectivement l'intégration de git dans eclipse/netbeans/idea actuellement c'est vraiment pas ça. C'est de toute façon un facteur bloquant pour migrer.

    • [^]Re: Merge

      Posté par Julien Portalier (page perso, ) le 22/06/2008 à 02:13. (lien). Évalué à 2.

      Je n'ai jamais eu tous ces problèmes lors de merge back avec subversion, même lorsque les modifications sont particulièrement lourdes, touchent à tout, effacent et déplacent des fichiers. Par contre il faut que la branche soit parfaitement synchronisée avec le trunk avant de tenter le merge back.
      
      Mais les branches sont en effet lourdes à gérer, subversion n'est pas (encore) vraiment adapté à la gestion de branches, et apparemment c'est toujours pas prêt de devenir simple. Ça marche, mais il faut bien tout noter : à quelle révision on a créé la branche ; la dernière révision du merge avec le trunk ; la dernière révision du merge back ; etc.

      • [^]Re: Merge

        Posté par Alban Crequy (Jabber id, page perso, ) le 22/06/2008 à 15:19. (lien). Évalué à 3.

        Ça marche, mais il faut bien tout noter : à quelle révision on a créé la branche ; la dernière révision du merge avec le trunk ; la dernière révision du merge back ; etc.
        
        Ces informations sont enregistrées automatiquement dans une propriété SVN lorsqu'on utilise svnmerge.py. Comme le note cykl, l'outil n'est pas parfait. Mais c'est tout de même mieux que d'utiliser les outils SVN de base.

• [^]Re: Merge

  Posté par Mildred (Jabber id, page perso, ) le 22/06/2008 à 12:36. (lien). Évalué à 3.

  Clairement, j'ai plusieurs fois essayé de faire des merges avec subversion ... c'est impossible. Déjà la commande svn merge est très peu pratique (il faut trouver les numéros de révisions à la main) et il faut comprendre comment elle fonctionne.
  
  C'est pour cela que je n'aime pas trop utiliser svn pour des choses un peu complexe.
  
  Par contre l'avantage de svn par rapport aux dvcs c'est qu'il est possible de décomposer un projet en sous projets, et de faire un checkout du sous projet uniquement. J'aimerais bien voir la même chose dans Mercurial (prévu mais pas implémenté).

  --
  La Roue du Temps

  • [^]Re: Merge

    Posté par or zax () le 22/06/2008 à 21:40. (lien). Évalué à 3.

    Pour le découpage en sous projets dans mercurial il faut activer l'extension forest.

  • [^]Re: Merge

    Posté par Laurent Morel () le 24/06/2008 à 13:17. (lien). Évalué à 3.

    Ben justement la version 1.5 était attendue depuis longtemps pour cela, simplifier les merges en conservant des informations sur ce qui a déjà été intégré.
    Comme c'est très complexe (et qu'ils ont placé la barre très haute je crois) il n'ont pas pu tout faire encore. Mais dans les cas standard, c'est simple :
    http://blog.red-bean.com/sussman/?p=92