Depuis quelques années je tente d'initier mes étudiants (BTS IRIS) au développement et à la gestion de projets. En gros on travaille pendant 4 semaines sur le développement d'un petit jeu en 3D/Réseau/C++. Jusque là j'utilisais Redmine+SVN+Eclipse+Subclipse. Mais j'ai aussi beaucoup entendu parler des SCM décentralisés comme GIT ou Mercurial. Cependant il semblent plus complexes à apprivoiser que SVN, et je me méfie de l'effet "mode" (dont semble jouir Git par exemple).
J'aurais donc besoin de vos avis, vous qui travaillez sans doute avec ces outils et qui avez le recul nécessaire, dont je ne dispose pas.
Bref est-ce que ça vaut le coup pour des étudiants de se plonger dans Git ou Mercurial en lieu et place de SVN et si oui lequel choisir ?
Merci d'avance pour vos précieuses contributions.
Forum Programmation.autre Quel SCM ?
4
oct.
2009
# sans être un expert en SCM
Posté par nanard . Évalué à 2.
Je ne connais pas Mercurial, par contre j'utilise git, la meilleur chose que tu puisse faire c'est de le tester et de comparer. Il existe de la doc en pagaille (officiel) pour une prise en main rapide et aisé.
Je te le recommande.
" Ca y est j'ai posé mon troll, vie et grandis mon petit. Que la plèbe te soit favorable "
Allez tous vous faire spéculer.
[^] # Re: sans être un expert en SCM
Posté par GTof . Évalué à 3.
Spleeeeennnnnddiiiide ! Tout en puissance et en finesse, le plus beau laché de troll qu'il m'ai été donné de voir depuis quelques temps. Et on est même pas vrendredi en plus ...
PS: C'est quoi le rapport entre rails et le développement d'un 3D/Réseau/C++ ?
[^] # Re: sans être un expert en SCM
Posté par nanard . Évalué à 1.
Aucun. Le rapport est sur sa phrase:
et je me méfie de l'effet "mode" (dont semble jouir Git par exemple).
J'ai découvert RoR et Git à peu prés au même moment. Tu parle Git je pense RoR, ajoute à ceci le terme "effet de mode", et mon cerveau fait une corrélation. Un vrai volcan cette phrase :) .
D'autent plus que oui, j'ai testé les deux par ce que c'était en vogue, mais j'en ai quitté un. L'autre projet ne méritant pas, amha, l'étiquette "effet de mode".
Allez tous vous faire spéculer.
[^] # Re: sans être un expert en SCM
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: sans être un expert en SCM
Posté par David FRANCOIS (site web personnel) . Évalué à 0.
# Modeste contribution.
Posté par GTof . Évalué à 3.
C'est vrai que Git est à la mode mais il le vaut bien, il est rappide, efficace, détaillé (il donne plein d'information lors d'un commit ou autre ce qui est très sympa pour savoir ou on en est dans son projet) et très riche (même si pour ma petite utilisation j'utilse pas 10% de ces fonctionalités). Bref j'étais également sceptique au début sur Git mais un ami me l'a fait essayé, je l'en remercie.
La model decentralisé n'est pas vraiment plus complexe que le modèle centralisé. Une fois qu'on a assimilé que chaque répertoire de travail est un dépot comme les autres cette "complexité" n'existe plus. Un avantage c'est que c'est plus flexible, ce qui est pratique quand tu veux pousser des patchs dans un dépot mais pas dans un autre (si si ca sert).
Avant Git j'utilisait darcs, l'avantage c'est qu'il est ultra simple, mais aussi plus lent. D'ailleurs un gros projet comme le compilateur Haskell principal (GHC) est passé de darcs a git pour des raisons d'efficacité.
Pour Mercurial, jamais utilisé personnellement mais certains projet auquel j'ai gouté l'utilise et en sont contents.
Pour finir je pense que pour une utilisation basique, l'un ou l'autre c'est à peu prè pareil. Les différences doivent se voir soit pour un gros projet, soit pour une utilisation avancée. Tout dépend de ce que tu veux leur apprendre.
[^] # Re: Modeste contribution.
Posté par Adrien . Évalué à 2.
Quand à l'utilisation je te rejoint totalement, le modèle décentralisé est très intuitif, bien plus que le modèle centralisé à la svn pour moi.
[^] # Re: Modeste contribution.
Posté par Mildred (site web personnel) . Évalué à 4.
Pour moi, les différences que je vois sont:
- Dans git, tu peux perdre des commits facilement (par exemple en faisant un rebase, tu as des commits équivalents, mais pas exactement les même). Mercurial est beaucoup plus prudent je crois
- Avec git, lorsque tu clone un repository (pour travailler dessus en local par exemple) tu ne copies en fait que la branche master (en général). Ce qui fait que si tu partages à ton tour ton repository, tu ne partages que la branche master et pas les autres. J'ai trouvé ça inconfortable pour faire des échanges de commits entre un portable et une station via un repository sur clef usb.
- Dans Mercurial, chaque commit est associé à une branche. Ce qui fait qu'il est possible pour une branche d'avoir plusieurs têtes (heads). Avec git, seules les têtes peuvent être associées à une branche, et une branche ne peux avoir qu'une seule tête. Avec Mercurial, les merges se font entre plusieurs têtes de la même branche en général alors qu'avec git, c'est entre deux branches, la branche origin/branchname et branchname.
- git est populaire et avance très vite.
- git peux être difficile à prendre en main au départ
- le livre Mercurial est très bien fait
- git te laisse accéder à ses couches bas-niveau facilement
# pourquoi changer ?
Posté par 태 (site web personnel) . Évalué à 2.
# DVCS vs VCS
Posté par nomorepost . Évalué à 5.
Avec un DVCS, les branches sont incontournables.
Les branches sont les propriétés exclusives de chaque développeur.
Lorsque tu clones ou que tu te synchronises une archive, tu récupères les branches des autres mais tu ne dois pas travailler dans leurs branches car ces outils ne gèrent pas la concurrence d'accès à une branche. Tu dois donc forcément te créer une branche (ou un fork avec Mercurial) pour travailler puis merger le travail des autres dans ta propre branche. Chaque développeur est donc propriétaire d'une branche et la version de réference correspond à celle d'un unique intégrateur. C'est pourquoi on parle de modèle user-centric par rapport à repository-centric. Dans la pratique il est possible de pusher dans la branche des autres mais c'est avec le risque d 'avoir 2 versions différentes au lieu d'une seule HEAD.
Les outils centralisés gèrent la concurrence au niveau d'une branche au moment du commit. Il n'y a tjs qu'un HEAD mais il faut merger dans son worspace pour commiter si des versions intermédaires ont été commtées depuis le dernier update.
Le modèle DVCS ne prend pas en charge le schéma de concurrence pessimiste (lock/modify/unlock) et si ton projet comporte beaucoup de type de fichiers non mergeables (modèles UML fragmentés, artworks, XML, ...) ou que les développeurs préfèrent cette approche, les DVCS ne sont pas une bonne idée.
De même, l'intégration continue est plus complexe avec les DVCS puisque chacun bosse dans sa branche et qu'un integrateur est nécessaire.
C'est possible de le faire mais plus complexe.
Autre différence les DVCS ne suppportent pas les partial checkout. On ne peut pas extraire de sou-partie d'un projet mais ca n'est pas un problème puisque le checkout est très rapide (en local)
Les DVCS sont aussi très appréciables pour leur performances (Tout est en local et seules les synchro d'archives nécessitent des comms).
Il est aussi possible de commiter plusieurs change request en étant déconnecté.
Enfin leur gestion des branches est à des lieues de ce qu'est et ne sera pas SVN avant un moment.
SVN ne supporte pas le "true rename" et c'est repoussé sans arrêt.
La mémoire de merge n'est pas encore au point.
http://subversion.tigris.org/issues/show_bug.cgi?id=898
http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Quel developpeur Eclipse n'appréhende pas le refactoring dans une branche
qui pourrira toutes les autre branches au moment du merge.
Il n'a souvent pas d'autre choix que de refaire le refactoring à la main dans chaque branche. On comprend que ca dissuade de brancher trop souvent.
Ceci est une époque révolue avec les DVCS qui sont basés sur des DAGs
Bref si pour vous les schéma de lock et l'intégration continue priment, gardez SVN sinon sautez le pas , d'autant que ca peut se faire en douceur car tous les DVCS savent se connecter à un depôt SVN.
A ma connaissance Bazaaar est le seul outils libre a supporter ces 2 modes nativement mais au prix d'une certaine lenteur par rapport à ces concurrents DVCS
Good Luck
# Merci
Posté par sauce_oluma . Évalué à 1.
C'est vrai qu'avec SVN, le développement du projet se déroulait à peu près bien, et changer de SCM n'a d'autre objectif que de coller au plus près à ce qui se passe entreprise. D'où ma question sur ces excellents forums ...
J'ai pû tester furtivement Git et Mercurial, les premières impressions :
- 10000 commandes pour Git Sachant qu'en plus on utiliserait au mieux 5% des commandes existantes. Moins de commandes pour Mercurial
- une documentation pas toujours très claire pour Git. Il va falloir sacrément débroussailler le terrain. Ca semble un peu mieux côté Mercurial, mais y aura du travail aussi
- l'accès au dépôt en HTTP semble être possible pour les 2
- les performances semblent être du côté de Git. Quoique pour gérer nos 30 fichiers cela ne devrait pas être trop pénalisant
- la couleur dans la console pour Git. Trop classe.
- branches faciles priori à gérer pour Git. 3 ou 4 méthodes différentes pour Mercurial qui était pourtant censé être plus simple.
- pas encore tester les IHMs (plugins Eclipse, TortoiseXXX). Je pense pourtant que la différence se fera dessus en ce qui nous concerne, notamment le support Windows.
- Redmine gère les 2
- Git semble être la référence actuelle des SCM distribués. Autant travailler avec la référence.
[^] # Re: Merci
Posté par NeoX . Évalué à 2.
[...]coller au plus près à ce qui se passe entreprise[...]Git semble être la référence actuelle des SCM distribués. Autant travailler avec la référence. [...]
il me semblait que le principe de la formation etait de former à une logique un etat d'esprit, pas à UN outil...
c'est comme ca que pendant des années on a eu des gens formés à WORD, et pas au Traitement de Texte
du coup, quand on leur parle Openoffice, Koffice, ABiword ils sont perdus
alors que la logique d'un traitement de texte reste la meme.
pour une gestion de projet de developpement, l'interet est de connaitre la methode (mieux vaut un SCM que pas du tout), savoir qu'il en existe d'autres...
mais "coller" à la realité de terrain :( si ca se trouve ce ne sera plus GIT (pour une raison X ou Y...) et tes etudiants quand ils vont sortir de l'ecole seront bien embété.
[^] # Re: Merci
Posté par sauce_oluma . Évalué à 1.
[^] # Re: Merci
Posté par nomorepost . Évalué à 3.
Les performances semblent être du côté de Git. Quoique pour gérer nos
30 fichiers cela ne devrait pas être trop pénalisant
...
- pas encore tester les IHMs (plugins Eclipse, TortoiseXXX). Je pense pourtant que la différence se fera dessus en ce qui nous concerne, notamment le support Windows.
Le support de Git pour Windows est encore balbutiant.
Jusqu'à peu, il fallait impérativement Cygwin
Aujourd'hui un port natif existe:
http://code.google.com/p/msysgit/
mais il n'est pas encore réputé stable.
Enfin, au niveau des performances, attends toi à un décalage avec Linux
Les branches faciles priori à gérer pour Git. 3 ou 4 méthodes différentes pour Mercurial qui était pourtant censé être plus simple.
Détrompes toi, avec Mercurial, il faut juste intégrer le fait que plusieurs heads peuvent coexister dans une archive et qu'il faut les résoudre.
L'avantage c'est que tu n'es justement pas obligé de brancher lorsque tes besoin sont simples. (1 seul effort de developpement)
Tu clones, tu modifies, tu commites.
Tu pull, tu merges, tu commites
Les branches ne sont en fait qu'une étiquette que tu colles pour éviter de merger toutes les heads de ton archive lorsque tu as effectivement besoin de gestion parallèle.
Les branches s'apparentent à des "faisceaux" ou sous-graphes de commit
Avec Git la branche est une notion stricte. Une branche ne peut pas avoir 2 heads.
Git semble être la référence actuelle des SCM distribués. Autant travailler avec la référence.
Un conseil, ne fais pas la même remarque à propos de Windows et Linux ici ;-)
# Finalement, ce sera Mercurial
Posté par sauce_oluma . Évalué à 1.
Finalement après quelques jours de tests de Git et Mercurial, c'est Mercurial que nous allons retenir principalement pour :
- sa prise en main aisée
- sa documentation
- son support multi-os (Eclipse et TortoiseHg)
- python (on utilise déja MoinMoin et Django)
Bonne journée ou soirée, c'est selon
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.