Logiciel de gestion de version sur Mac: Tour d'horizon.
Mala
Membre, Modérateur
En lisant le post d'Olof, je me suis posé la question de savoir qu'est-ce qui existe sur Mac comme outil de gestion de version. Sorti de CVS et de son successeur Subversion, j'ai l'impression que c'est sacrément la misère de ce côté. Est-ce que certains connaà®traient d'autres alternatives sur Mac (payante ou non)?
Mon rêve serait:
- un outil à 99.9% graphique (visu des versions de fichiers, gestion des fusion, etc).
- taillé pour OSX niveau design (je suis pas venu sur Mac pour avoir des fenêtres à la Windows :P ).
- gestion du multi-branches (donc dehors la nouvelle mouture d'XCode pour Léopard).
- gestion de vues dynamiques (à l'inverse des vues snapshot que l'on trouve généralement, les vues dynamiques se mettent à jour dès qu'on fait des checkins entre collègues. ).
- intégration d'un gestionnaire d'anomalies.
- simplicité de configuration aussi bien en utilisation mono-poste que multi-postes.
Mon rêve serait:
- un outil à 99.9% graphique (visu des versions de fichiers, gestion des fusion, etc).
- taillé pour OSX niveau design (je suis pas venu sur Mac pour avoir des fenêtres à la Windows :P ).
- gestion du multi-branches (donc dehors la nouvelle mouture d'XCode pour Léopard).
- gestion de vues dynamiques (à l'inverse des vues snapshot que l'on trouve généralement, les vues dynamiques se mettent à jour dès qu'on fait des checkins entre collègues. ).
- intégration d'un gestionnaire d'anomalies.
- simplicité de configuration aussi bien en utilisation mono-poste que multi-postes.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'ai un peu l'impression que c'est quel que soit la platteforme actuellement. Subversion est vraiment le poids lourd.
Donc avec ça, tu exclus en gros tout, sauf SVN, CVS dans une moindre mesure et PeForce (dont la seule UI à ma connaissance est dans Xcode). Mais bon, il existe des UIs pour subversion, comme svnx. ça n'est pas vraiment un iApp niveau interface, mais ça dépanne lorsque Xcode ne se montre pas à la hauteur.
Je crois que ça a été ajouté pour les petits dévelopeurs qui n'ont qu'un poste et qui ne veulent donc pas se prendre la tête avec des configurations "lourdes". En gros, de ce que j'ai pu en comprendre, c'est plutôt pour ceux qui font une archive zip par version (sauf que j'imagine que s'ils intègrent la fonction, c'est pour permettre plus que les simples zip - parce que bon, les zip lorsqu'ils faut les explorer c'est pas top).
Je pense pas que ce soit un idée terrible: un changement fait par un collègue pourrait causer des modifications de comportement de la version sur laquelle on bosse, donc un tel comportement rendrait le débuggage encore plus complexe que ce qu'il est déjà .
Alors là , si tu oublies totalement ta revendication n°1, il existe des systèmes de suivis de version non centralisés, tels que ceux-ci:
http://en.wikipedia.org/wiki/Darcs
http://en.wikipedia.org/wiki/Mercurial_(software)
http://en.wikipedia.org/wiki/Monotone_(software)
http://en.wikipedia.org/wiki/SVK
Maintenant je n'ai aucune idée de ce que ça vaut en pratique.
Le plus répendu car gratuit et améliorant CVS ok mais Poids lourd???
Je dresse surtout un peu le tableau de ClearCase sur PC qui lui est vraiment un poids lourd (niveau tarif aussi d'ailleurs) avec en plus (mais qui ne m'intéresse pas perso pour mes besoins):
- gestion de bases multi-sites.
- optimisation de la compilation par partage des binaires (si ta config de compil est la même que celle de ton voisin, il va pêcher les binaires chez lui plutôt que de recompiler. De mêmoire ce n'est d'ailleurs possible qu'avec les vues dynamiques.).
Oui d'après ce que j'ai vu c'est du simple snapshot de base. Mais même en monoposte, du multi-branches aurait été très utile ne serait-ce que pour gérer une branche pour version stabilisé (sur laquelle on fait les corrections d'anomalies) pendant qu'on développe une toute nouvelle mouture en parallèle. C'est dommage, j'ai l'impression que comme a sont habitude, Apple ne va pas aller assez loin.
Pas terrible??? Tu rigoles, j'ai été administrateur ClearCase (sur PC et Silicon Graphics) pendant quelques années et les vues dynamiques sont un vrai bonheur à administrer et à utiliser. J'ai eu l'occasion de comparer à plusieurs reprises avec des collègues administrant en snapshot (sous ClearCase et PVCS notament) et je peux te dire que ceux qui avaient eu l'occasion de travailler en vue dynamique avant pleuraient. La grosse différence à l'usage c'est qu'on voit les problèmes au fur et à mesure. Du coup, en tant que développeur ont est face à ses "responsabilités" en temps réel. Et c'est d'autant plus simple d'apporter les correctifs que c'est tout frais dans sa tête. Pour l'administrateur, c'est aussi un confort car on te tombe beaucoup moins souvent dessus pour des problèmes de fusions indémerdables qui surviennent bien sûr toujours la vieille d'une baseline car tout le monde checkin à mort dans tous les sens à la dernière minute (car en snapshot les developpeurs lambda ne prennent jamais le temps de mettre à jour leur capture régulièrement d'eux même bien sûr...
Ayant bossé et bossant actuellement sur des projets découpé en une multitude de modules, interdépendants ou non et parfois multiprojets, j'ai eu l'occasion d'essayer le checkin/checkout automatique...
Ben perso ça a plutôt été la zone pour nous et on est vite revenu à un fonctionnement classique de SVN : on ajoute les fonctionnalités voulues au module dont on a la charge, on fait les tests u, et qd c'est bon on fait un update et on recompile pour valider, puis on commit.
Comme on a des scripts de pre-validation pour le commit (je sais pas comment ça marche sous le capot c'est pas moi qui ai mis ça en place), on est obligé d'associer un commit avec notre outil de tracking (en mettant art #NNN pour indiquer la tache ou le bug ou l'amélioration... en rapport avec la modif) ce qui fait qu'on sait parfaitement à quoi correspond chaque commit.
Donc couplé ainsi au système de tracking, c'est plutôt efficace.
Avec le checkin/checkout automatique (snapshot dynamique ?), pendant qu'il y en avait un qui était en train de bosser sur un gros truc, et que les autres faisaient des modifs, genre modification de l'API, ça impactait directement alors qu'on avait autre chose à penser de notre côté en développant notre gros truc que mettre tout de suite à jour l'API (on peut avoir prévu de ne voir ça que dans un 2e temps, préférer finir notre gros truc avant par ex). Donc côté gestion des priorités et des tâches, tout le monde s'impactait sur tout le monde sans laisser le choix de savoir quand on règlerai tel ou tel souci ou intégrerai telle ou telle nouveauté.
Et ça c'est de mon point de vue une horreur côté organisation quand on fonctionne par modules comme nous !
De toute façon à mon avis le mieux c'est SVN couplé à autre chose (outils de tracking, de tests, de managment), y'a en général de quoi faire (parce que si tu cherches un tout en un tu ne vas pas trouvé ton bonheur je pense, alors que SVN + tracking system + gestion projet tu pourras agencer ça comme tu veux)
Poids lourd car il "écrase" tout sur son chemin (enfin ...CVS plutôt). Mais à utiliser je le trouve très agréable et c'est loin d'être une usine à gaz.
Sinon je pense qu'une de ses raisons de son succès est ...son succès: il y a des tas d'outils qui peuvent "s'intégrer" à un dépôt SVN: comme trac pour le suivi de bugs par exemple, un plug-in pour le Finder ou encore SVK qui peut-être utilisé pour le multisite.
À voir, on ne sait pas grand chose sur la manière dont ça fonctionne. Ce que je pense, c'est que ça s'adresse à un public donné, mais ce n'est pour autant que les autres publics sont abandonnés: à chaque version de Xcode, on a eu droit à des améliorations des systèmes de gestion de code source "traditionnels", je serais surpris qu'il n'y aucune amélioration sur ce plan à cause des snapshots.
Oups, je pensais que ça faisait partie du "SCM de rêve", je ne savais qu'il existait déjà des systèmes qui le faisaient. Mais bon, je reste quand même sceptique: ce que Ali évoque est justement ce que je craignais. Mais si un jour j'ai l'occasion de tester, je la prendrai.
Mais avant, je me renseigne sur SVK: il est visiblement basé sur SVN, et avoir un système décentralisé m'arrangerait assez bien.
On peut créer une interface graphique avec SVN qui gère tout ça je pense...
Le plus difficile est la gestion de vues dynamiques, mais ça doit être jouable avec les notifications FSEvents (ceci-dit, pas sûr que ça soit une bonne idée aussi...)
Okay... j'avais compris ça dans l'autre sens.
Faut associer un autre système client / serveur à SVN alors... Peut-être avec Bonjour...
Pour tout te de dire j'évoluais dans un environnement assez similaire avec des dizaines de projets de DLL sous Visual, bien sûr interconnectées sinon se serait pas drôle ;D , et réparties sur une trentaine de développeurs sur deux sites différents. Maintenant ta réflexion ne me choque pas pour autant. En fait, c'est un question d'éducation à l'utilisation essentiellement (l'administrateur de gestion de version a donc son rôle à jouer). Les gens formés à la logique des vues snapshot ont du mal a se faire à l'idée des vues dynamiques et vice et versa j'ai l'impression. Les vues dynamiques demandent en effet plus de rigueur. Par exemple, quand tu me parles de modifier une API (donc impact potentiel important) dans la même branche que le collègue et que ça checkin à toute volée moi sa me hérisse les cheveux
Mais si tout le monde fait comme ça. Pourquoi y aurait-il plus de problèmes avec des vues dynamiques?
J'avais étudié un peu CVS comme solution "low cost" (ok, c'est gratuit mais il faut aussi intégré les coût de formation/maintenance) pour une autre équipe mais je doute que ce type de structure supporte une approche dynamique. C'est pas simple je pense.
Oui tout à fait.
Mais moi pour ma part ce qui me gène quand même énormément sur l'aspect vue dynamique, c'est que ta working copy, et donc ton code source, est modifié même quand tu es en pleine phase de debug (où tu as déjà assez à te soucier). D'une part tu as moins de visibilité j'ai l'impression sur ce qu'on fait les autres (quand tu fais un update tu peux regarder le log de l'update et voir "ah oui tiens il y a eu un commit pour corriger ça ou modifier telle API ou autre"), c'est du coup un peu trop transparent.
Genre tu fais des tests, en essayant 2 ou 3 versions de ton code, de ton côté sans vouloir déranger les autres, donc sur ta working copy tout seul sans impacter. Tu essayes la première façon de faire, puis une 2e, et tu t'aperçoit que la 2e ne marche pas... alors que pour toi tu n'as changé que ton petit bout de code. Alors qu'en fait en creusant tu réalises que si cette 2e version ne marche pas c'est parce qu'entre temps ta working copy s'est mis à jour suite à un commit d'un de tes collègues. Certes, il avait qu'à commiter un truc qui marche (quoique c'est pas forcément un bug de sa faute, ça peut être justement une modification prévue de l'API, même si c'est rare je prend cet exemple car il est simple mais parlant), mais en attendant ça te pourrit ton code, ta phase de dev et de test, sans trop te prévenir.
En fait, ce qui me gène je pense c'est surtout que ta working copy soit impactée par les commit des autres sans prévenir et sans que tu puisses choisir.
Le must, pour concilier les 2, ce serait d'avoir juste des alertes lorsqu'il y a des commit de faits. Genre un petit soft qui fait des notifications, ou un RSS recensant tout les derniers commits faits sur le repository, comme ça tu serais informé que dernièrement untel a commité tel truc, untel tel autre truc, et tu pourrais t'organiser en te disant "ah tiens il serait temps que je fasse un Update" ou "ah tiens ce truc a été modifié justement je tape dedans aussi je ferais bien d'aller y faire un tour finalement ça règle peut-être mon bug, en cascade".
Une idée de dev, ça ? un soft indiquant la liste des commits à la manière d'un RSS et avec alertes growl ? (Bon ok normalement si on a bien synchronisé les outils, on peut aller dans l'outil de gestion de projet et voir les derniers bugs/tasks/improvments qui sont passés à "résolu" par exemple, mais ça demande une démarche (du même ordre que la démarche de penser à faire un Update, limite, voire pire) que finalement on ne fait pas systématiquement. Alors qu'avec des notifs et un affichage accessible en un clic voir présent en tant que palette ou dans la barre des menus, avec un affichage encore plus visible si le nombre de commits faits depuis la dernière update dépasse un certain nombre, etc... y'a de quoi nourir le projet, s'il y en a qui sont en mal de dev, ça peut être une idée
Le problème c'est que quand on est habitué à travailler en Snapshot on ne va pas avoir ce reflex (c'est aussi valable pour les administrateurs s'il n'ont pas intégré cette logique).
parce que pour moi le principe de faire autant de branche que de personnes ça me parait abhérant, surtout pour une équipe genre 50 personnes facile (et quand tu penses que sur le serveur, qui dit branche dit copie complète de tout le dossier sous SVN donc de tout le projet, dupliqué 50x donc pour mon exemple).
Alors que les working directories servent à ça.
J'ai du mal à voir l'intérêt de faire une branche de test quand on a des working directories en fonctionnement "classique" : on fait directement nos tests sur ce qu'on a modifié, et on commit que quand c'est pret. Ce qui responsabilise car oblige à faire des tests avant de faire remonter le code. Alors qu'avec des branches on a tjs le risque de ne pas avoir la même version du code sur 2 branches (puisque c'est le but principal des branches), et du coup de risquer de tester une version qui n'inclut pas toutes nos modifs.
Et sinon pour les autres cas je ne vois pas la différence : d'une pour notre système de tracking (système "codex" interne) on a un suivi précis des versions associé à chaque commit, bug tracking et résolution, etc. Ca m'est ainsi déjà arrivé de remonter à la version de tel jour à telle heure sans pb. Que ce soit en la récupérant dans mon working directory ou en naviguant avec le repository browser de TortoiseSVN sans la récupérer en local (Et je ne vois que ça aussi) : que ce soit pour remonter à une date précise, ou remonter à la version où telle ligne de code a été injectée... Et de ce côté là je ne pense pas qu'il y ait de différences entre les 2 modes.
ça ce n'est pas propre à ClearCase ou au vue dynamiques. On peut faire exactement la même chose avec SVN (c'est même pour moi la moindre des choses pour un système de travail collaboratif).
Une petite note si tu ne connais pas SVN: ce n'est pas parce qu'il ne semble pas voir une fonction qu'elle n'est pas permise: le cas des branches dans SVN est un bon exemple. On peut définir une branche comme une copie d'une "vue" sur laquelle on travaille indépendamment. Si on regarde la doc et les commandes, on a pas l'impression qu'il n'y a rien de spécifique aux branches, mais dans l'esprit SVN, il ne s'agit au final que d'une copie de fichiers dans un autre dossier, qu'on a définit arbrairement comme étant un répertoire consacré aux branches, mais ce n'est qu'un convention "utilisateur": Subversion ne le gère pas le dossier de manière différente des autres. Tout comme les labels ne sont que des copies de vues dans un répertoire donné, répertoire auquel on donne le sens "label" (enfin, on dit plus souvent "tags", mais c'est juste une question de convention).
Si tu fais la copie dans les règles, c'est à dire en utilisant la commande "svn copy" au lieu de bête copie de fichiers + "svn add", il n'y aura pas de copie en plus sur le serveur. SVN te fera croire qu'il y a copie, mais en terme de DB au niveau du dépôt, il n'y aura pas de duplication de donnée.
J'en vois 2:
- si on fait un gros changement, on peut faire le travail sans perturber les collègues, tout en bénéficiant encore des avantages d'un système de suivi de version (ne pas utiliser de suivi de version dans le cas d'un gros changement en ne bossant que sur sa working copy perso reviendrait à se mettre dans la "position" qu'un dev solo sans suivi de version - alors que même pour un solo, le suivi de version est utile).
- en général, niveau backup, les boites accordent plus d'importance au dépot SVN/CVS/ClearCase/Perforce/... qu'aux postes individuels. Donc faire son travail dans une branche permet de s'assurer de la sauvegarde de ses données.
Si on travaille effectivement comme tu le dis à l'instant alors qu'elle est la différence puisque le code va être nickel chez tout le monde?
L'argument de volume n'a pas grand sens pour moi. C'est dérisoire par rapport au bien fondé de sécuriser le code pour les équipes de travail.
Renaud, j'allais valider ma réponse mais je viens de voir ton message. Je répond a ta question dans la foulée: c'est rarement le cas mis à part quand on veut vraiment s'isoler sur des points ponctuels. En pratique, on travaille dans la branche principale en pensant aux autres quand on va faire ses checkins (donc tests et cie exactement comme pour du snapshot). Ca marche très bien et surtout les merges sont d'autant plus light qu'on a pas passé quinze jours ou trois semaines avec une version non à jour parce qu'on développait dans son coin.
A l'usage je trouve que le fait d'imposer de la rigueur en amont est payante et je l'ai constaté à plusieurs reprises. Je me répète mais c'est vraiment une question de philosophie.
Merci pour le complément d'info sur SVN. Je n'avais bien sûr aucune prétention de dire que ça n'existait pas chez les autres outils de gestion. C'était juste pour mettre en avant la philosophie implicite qui me semble, comme tu le soulignes ensuite sur la gestion de branches, plus carrée dans son approche.
- on travaille dans les 2 cas sur la branche principale
- on est obligé de faire ses commit à intervalles fréquents
- on est obligé d'avoir la même rigueur, car dans les 2 cas, on emmerde les collègues si on fait de trop changements à la fois...
La seule différence serait alors qu'en snapshot on choisit le moment où on fait sa mise à jour (sachant qu'un commit ne peut pas fait être si la copie locale est plus ancienne que la version sur le dépôt - pour svn en tous cas) et qu'en dynamique, il ne faut rien faire du tout. Donc à la limite, la différence de "philosophie" pourrait se résumer à une case à cocher dans les préférences d'un client avec UI.
J'ai l'impression que ce que tu trouves mal à la technique snapshot est le résultat de sa mauvaise utilisation, mais que bien utilisées, les 2 techniques sont très proches. Est-ce que je me trompe?
T'inquiètes, je ne l'ai pas pris comme ça. Si tu n'as jamais utilisé SVN et que tu t'es contenté de parcourir la liste des commandes, c'est un fait que SVN ne contient rien de spécifique aux branches ni aux labels. ça en a dérouté (et en déroute encore) beaucoup qui viennent d'autres systèmes. Mais bon, là c'est une question spécifique à SVN, pas à la comparaison dynamique/snapshot.
Oui moi aussi, j'en arrive à la même conclusion à te lire.
Effectivement je comprends mieux.
En fait le problème c'est que d'un côté (updates/checkouts manuels) les gens mal formés à cette utilisation oublieront de faire leurs updates et se retrouvent avec des versions qui dates de 3 plombes (ceci dit ça veut un peu dire qu'ils développent tout seuls dans leur coin, donc ce n'est pas une philosophie très collaborative je trouve mais bon). Et que de l'autre côté (update automatique / mode dynamique) les gens auront toujours la dernière version commitée sans avoir à déclencher le checkout... même s'ils n'avaient pas envie de mettre à jour tout de suite
C'est pour ça que j'en étais arrivé à la conclusion que le meilleur compromis pour moi ce serait un SVN avec checkout/update manuel, mais système d'alerte/surveillances des derniers commits (RSS, notifications [email, growl, ...], petit soft indiquant à l'écran le nombre de commits depuis ta dernière update, etc...).
Ou alors un prompt explicite genre "un commit a été détecté, voulez-vous mettre votre working copy à jour ?"