Versionning de projet et SCM (CVS, SVN, Mercurial, Git, ...)
zoc
Membre
[EDIT modo]Ce sujet est la suite de la discussion commencée ici.[/EDIT]
GitHub, c'est un service permettant à quiconque de proposer un dépôt Git public pour diffuser ses codes sources, pas un outil de tests U
Git est un SCM décentralisé, au même titre que Mercurial ou Baazar. D'ailleurs, personnellement, j'ai abandonné subversion pour Mercurial car il a l'avantage de ne pas foutre des dossiers cachés dans chaque dossier du projet, et qu'il s'intègre parfaitement dans redmine
GitHub, c'est un service permettant à quiconque de proposer un dépôt Git public pour diffuser ses codes sources, pas un outil de tests U
Git est un SCM décentralisé, au même titre que Mercurial ou Baazar. D'ailleurs, personnellement, j'ai abandonné subversion pour Mercurial car il a l'avantage de ne pas foutre des dossiers cachés dans chaque dossier du projet, et qu'il s'intègre parfaitement dans redmine
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
J'avais essayé Mercurial à une époque et j'avoue que je suis pas fan des SCM décentralisés, je vois bien l'intérêt que ça a, mais avoir une sorte de double-commit (commit+push) et ne plus trop avoir un référent donné sur lequel on est sûr qu'il y a la dernière version, ça me gêne un peu, enfin j'ai du mal à m'y faire.
Et puis du coup quand on bosse à 50, qui a la dernière version du projet ? faut que les 50 personnes push toutes l'intégralité du projet sur les 49 autres pour être sûr que tout le monde est à jour, non ? Ou alors que tout le monde push sur un poste unique, puis update depuis ce poste unique... ce qui finalement ressemble à un SCM centralisé !
Bon de toute façon le souci c'est que Mercurial n'est pas intégré à Xcode (quoiqu'entre nous en fait je n'utilise pas le SCM de Xcode, trop pauvre et pas super bien foutue leur interface, je préfère le plugin du Finder (qu'on trouve chez tigris) ou finalement la ligne de commande, mais bon), mais surtout qu'en l'occurrence le SCM c'est le client qui l'a choisi, donc je suis obligé d'utiliser SVN 1.6 :P
De toute façon c'est comme je disais plus haut, je suis partant pour tester d'autres solutions (Git pour le SCM, en remplaçant de SVN, et GH-Unit pour les TestsU en remplacement de SenTestKit/OCUnit) mais encore faudrait-il avoir le temps :P (remarque je vais pas me plaindre d'avoir du boulot 8--))
Toute la communauté Rails y est passé d'ailleurs. Pour ma part, je suis toujours en SVN sur mes projets Web, mais il me casse souvent les...
C'est en effet effectivement ce que l'on fait (moi je le fais sur mon "serveur" redmine perso, mais il existe des solutions en ligne pour mercurial, comme www.bitbucket.org).
Et je suis d'accord, cela ressemble du coup à un SCM centralisé. L'avantage de la solution décentralisée, c'est qu'elle te permet de faire des "commits" sans avoir accès au dépôt central, ce qui peut avoir un avantage certain pour l'organisation du travail (genre je n'ai pas accès au dépôt, mais je peux quand même commiter une à une les features que j'implémente, avec des messages expliquant chaque commit afin de pouvoir s'y retrouver).
Moi j'utilise Version.app pour les dépôts SVN car je n'étais vraiment pas satisfait du plug-in pour le Finder, et je suis en train de développer un outil équivalent pour Mercurial (mais je manque cruellement de temps pour que cela avance... En fait j'ai tout un tas de projets en tête, que ce soit pour iPhone ou Mac, mais pour y arriver il faudrait que mon boss m'offre quelques mois de vacances)
Déjà que j'ai plein de projets (pro comme perso) en attente dans les bacs, faut que j'arrête d'avoir des idées en plus qui me donnent envie de les développer ;D
http://mooseyard.com/Jens/2009/04/murky-a-mercurial-client-app/
Pour git:
http://gitx.frim.nl/
Je connais, et je l'utilise actuellement, mais l'interface ne me plait pas, c'est pour cela que je veux faire mieux
Et de plus, il manque tout un tas de trucs à Murky que je trouve indispensable (comme la gestion des merge).
Par contre, sur le wiki de SproutCore, il y a une page qui explique comment utiliser GIT pour développer SproutCore. Ca pourrait en intéresser quelque uns !
C'est là : http://wiki.sproutcore.com/Git+Workflow-Contributor
J'utilise ClearCase au boulot, c'est mon premier contact avec les gestionnaires de version.
Meme si ClearCase est assez complique, j'aime le fait de pouvoir voir l'historique de mes fichiers, recuperer des modifications ... j'aime bien le concept des logiciels de gestion de version quoi !
Donc j'aimerais bien mettre cela en place pour mes petits developpements personnel. Je sais que dans Mac SVN est integre d'office, et j'aimerais savoir connaitre les solutions disponible pour pouvoir avoir mon projet sur le web quelque part, afin de permetre a des amis de developper avec moi !
Merci,
F
Je sais que cela ne répond pas directement à ta question, quoique ça peut être une solution si tu as un Mac qui peut être utilisé en tant que serveur (toujours allumé et accessible depuis l'extérieur par tes amis quand ils ont besoin de bosser sur le projet), mais il est bon de savoir ceci :
- Il est possible de créer un serveur SVN local, c'est à dire sur sa machine, ou sous toute autre machine Mac... (bon c'est possible sur un PC, aussi mais ça nécessite d'installer des trucs, alors que sous Mac c'est intégré. Oui, même le serveur SVN est intégré.)
- Mais en plus et surtout, c'est vraiment pas compliqué à faire : y'a pas plein de config partout ou des commandes alambiquées (... même si on peut rentrer dans le détail de la config si on veut, mais dans 80% des cas c'est pas utile)
- Et il n'est pas compliqué non plus de créer un serveur SVN, c'est à dire en plus de créer un repository SVN sur un Mac, de faire en sorte qu'il soit accessible aux autres Macs et de l'utiliser comme un repository du net, genre d'un site comme sourceforge ou autre.
Suivez le guide :
Exemple, pour créer un repository nommé "svn-repo" à l'endroit actuel (qui par défaut est "votre maison", soit [tt]~/[/tt], quand vous ouvrez un nouveau terminal) :
Exemple, pour faire un checkout dans "~/svn-wc" du repository (vide) que l'on vient de créer dans "~/svn-repo" :
/!\ Attention bien sûr à ne pas confondre le repository (qui est habituellement sur un serveur distant mais est local ici) avec la copie de travail (working copie, qui est toujours sur votre poste) : comme le repository est local ici, il est facile de confondre les 2 au début... mais bon comme en pratique ce ne sont pas les mêmes arborescences etc, vous ne pouvez pas trop faire de bétises au final
Exemple, pour rendre accessible de l'extérieur notre repository précédemment créé :
Exemple, pour faire un checkout, depuis Mac2, du repository "svn-repo" créé sur (et déservi par) Mac1, dont le nom est disons "mac1.local" : [tt]svn checkout svn://mac1.local/[/tt]. Ou pour vérifier l'accessibilité et avoir des infos sur le repo de Mac1 depuis Mac2 :
Et voilà , en 2-3 commandes Terminal mais qui sont ultra simples, et surtout sans avoir rien à installer ni à configurer, on a un serveur SVN sur son Mac, et on a même pu le rendre accessible aux autres ordis étant sur le même réseau local (ou ayant accès réseau à ce Mac1 par quelconque moyen)
Perso je me sers parfois de ça pour mes projets persos, même si je bosse seul dessus, s'ils commencent à être conséquents, c'est parfois bien pratique.
PS : Attention pour svnserve, bien sûr si vous quittez votre session ou rebootez Mac1, le serveur SVN svnserve va s'arrêter... Il faudra bien sûr le relancer au prochain reboot/lancement de session pour pouvoir de nouveau accéder au repo de ce mac depuis un autre mac.
Hier j'ai suivi tes instructions, je n'ai pas encore cree de projet dans mon repository, je me suis arrete la.
Ce soir je vais essayer d'envoyer un petit projet java dessus.
Sinon il existe plein de sites qui permetten d'héberger gratuitement un dépôt subversion, comme Google Code (mais à priori réservé aux développement Open Source).
J'ai vu pour google, mais oui c'est reserve aux dev Open Soure. Et je prefererais me creer une petite solution a moi, afin d'apprendre a gerer un petit peu !
Merci quand meme pour l'info
F
Comme vous l'avez sans doute remarqué, avec Snow Leopard, les plugins de Menu Contextuel n'existent plus (ils sont remplacés par les Services, cf cette discussion).
Conséquence, le plugin "scplugin" de Tigris pour ajouter la gestion du SVN dans le Finder n'est plus accessible sous Snow Leopard. Comme ils le mentionnent sur leur site, ils comptent développer une version sous forme de "Services" à terme... mais ce n'est pas pour tout de suiteÂ
En attendant, j'ai découvert une alternative prometteuse (en attendant plus dédié) et que je suis en train de tester : passer par des scripts AppleScript.
Ouais, ça fait pas forcément "super propre" dit comme ça, mais après tout pourquoi pas
C'est par ici que ça se passe : y'a un screencast qui fait une démo du truc et tout ce qu'il faut pour l'installer dans le menu Scripts du Finder.
SCPlugin est opensource il me semble... donc rien n'empêche de reprendre les sources pour mettre à jour.
Par contre, il va falloir trouver une autre astuce car le plugin de SCPlugin hackait la fonction d'affichage des icônes dans le Finder en profitant d'être loadée dedans. Avec les Services, ça va être impossible.
- Pour partager mes diverses ressources de code & co à la communauté, je me suis créé un repository GIT sut github.
- Seulement voilà , mon repopository GIT ne représente pas un "projet" à proprement parler, mais est donc plutôt composé de dossiers et sous-dossiers contenant diverses ressources (code, classes, libs, textmacros, ...) indépendantes les unes des autres.
Mais du coup le problème c'est que quand qqun veut accéder à seulement une de mes classes que je partage par exemple, j'ai bien l'impression, à moins que je ne connaisses pas certaines subtilités particulières de GIT, qu'il est obligé de récupérer la totalité du repository GIT. Ce qui a un sens pour quand le repo contient tout un projet, mais dans mon cas ça a déjà beaucoup moins de sens car tout le monde ne sera pas intéressé par récupérer la totalité de ce que j'ai publié.
Sous SVN il y a moyen de récupérer qu'une sous-partie de l'arborescence d'un reposotory SVN, et ne travailler que sur cette partie. Sous GIT c'est pas possible ?
Du coup ça me pose des questions de ce côté sur GIT, j'ai ouvert une discussion ici sur github mais s'il y en a ici qui veulent donner leur avis... genre des habitués de GIT...
Mais maintenant que je vois certaines limitations de GIT d'un autre côté... bah du coup mon coeur balance...
Tu utilises quoi toi pour hoster tes projets partagés de manière générale ? github ? sourceforge ? google code ? autre ?
Tous les gros projets (Le noyaux Linux ayant été le premier, puisque Git a justement été développé pour lui) abandonnent progressivement SVN pour Git et (dans une moindre mesure) Mercurial. Il y a bien une raison: Ils sont bien plus efficaces quand le nombre de développeurs est important sur un projet.
Et dans le cas spécifique de MacOS X, comme le dit Ali, ne pas avoir son projet pollué pas des dossiers .svn à tous les étages c'est un gros avantage.
J'ai tendance à dire que GIT est merdique non pas sur le papier mais à cause de la ligne de commande qui va avec ! Certe c'est cool de plus avoir les .svn de partout, le système décentralisé peut avoir du bon, par contre la ligne de commande ils se sont raté en plein...
Il y a trop d'action pour faire un simple commit, d'ailleurs on est obligé d'écrire commit en toute lettre, il n'y a pas de raccourcit type ci... Et lorsqu'on le fait, on est obligé de mettre un message de commit, un -m "" ne marche même pas ! Alors OK c'est pas bien de pas mettre de message de commit, mais ça reste à moi humain d'en décider, pas à la machine !
C'est pour ces détails que je n'aime pas GIT pour la ligne de commande qui va avec ! Sérieusement on dirait qu'elle a été faite par Microsoft ! Plein d'action de confirmation et des commutateurs à rallonge...
Sur ce point je ne suis pas d'accord.
Beaucoup de développeurs sont laxistes (moi le premier
A l'époque où j'utilisais svn, j'avais développé un "hook" coté serveur refusant les commit sans commentaires (et en l'occurrence, j'étais allé encore plus loin, puisque les messages de commit devaient obligatoirement référencer un numéro de "defect/tache" de la base "trac" associée au projet).
Maintenant, moi qui était convaincu par GIT ces derniers temps et l'avait pas mal utilisé (si le seul reproche qu'on lui fait c'est la ligne de commande verbeuse, ça va c'est pas violent comme pb...), mon problème actuel me fait me poser des questions...
Pour rappel j'ai donc plein de "ressources" à partager (code, classes, etc) indépendantes les unes des autres, mais que j'ai organisé en dossier et sous-dossiers (Code/Classes/UI, Code/Classes/Métier, Code/Catégories, DevTools/TextMacros, DevTools/Templates, ...) et je voudrais non seulement avoir un versionning de tout ça (pour quand je fais évoluer ces bouts de code ou corrige des bugs dedans) mais les mettre à disposition de la communauté... tout en ayant cette contrainte donc, dont GIT ne semble pas pouvoir s'accommoder, de permettre aux utilisateurs (voire participants) de rendre le tout indépendant, et de pouvoir ne télécharger qu'une partie du repo (qu'une classe ou une catégorie) et pas être obligé de prendre tout.
J'ai bien pensé faire un repository pour chaque bout de ressource, mais d'une part ça commencerait à faire bcp de repos GIT, et en plus ils ne seraient pas organisés (donc mon arborescence Code/Classes, Code/Catégories, ... n'apparaà®trait plus)
Comment feriez-vous pour ce genre de ressources à partager du coup ?
Au final j'ai bien peur de devoir revenir a SVN qui a cet inconvénient d'avoir des ".svn" partout... mais ça a en contrepartie l'avantage de pouvoir faire un checkout que d'une partie (un sous-dossier) du repo...
Et après si je pars sur SVN, je ne sais pas quels services seraient les mieux (sourceforge, google code, autre...?)
Je crois que c'est à chaque équipe ici de décider quoi faire ! En aucun cas une méthode de code ne doit être imposée par un système de versionning ! Personnellement je suis seul sur mon repos et ça me les brise de devoir commenter à chaque fois ! Et quand je bosse en équipe, pas besoin de forcer les gens par la machine, un simple brefing correctement fait suffit !
Ce n'est pas à la machine de prendre la place du chef d'équipe ! Si tu as besoin de forcer tes dev à faire quelqu'un chose d'aussi évident que commenter c'est que tes dev sont des amateurs ou que le chef d'équipe est mauvais !
J'ai bossé sur différents projets avec SVN et avec des personnes telles que des managers (pour faire du versionning de docbooks de cours de management) et ça se passe sans aucun problème si on explique les choses correctement !
T'as de la chance alors...
Parce qu'en ce qui me concerne, je travaille dans une boite mi française mi italienne, et je t'assure qu'à chaque meeting "audio" hebdomadaire, on doit leur rappeler à nos "amis" italiens systématiquement toutes les consignes, parce que sinon ils font n'importe quoi.
Et d'ailleurs, rien que pour cela, on utilise le couple ClearCase/Clearquest, qui est encore bien plus contraignant que toutes les contraintes que tu cites. Sans cela, on perd 1/2 journée par semaine à réparer le bordel qu'ils foutent dans les différents dépôts.
On avait beau leur expliquer pédagogiquement, pas juste leur dire "faut faire ça" mais leur expliquer pourquoi, l'intérêt de suivre ces consignes et comment ça pouvait également leur faciliter la vie à eux-même... ça tenait 2 jours, et après c'était reparti pour les mauvaises habitudes.
Y'en a on a beau essayer dans tous les sens, y'a rien à faire...
(Bon heu et pour ma question sur le meilleur système pour gérer une arbo de trucs indépendants non rattachés à un projet ? personne ?)
Les rares exemple que j'ai pu rencontrer c'était un gros repo avec pour chaque projet un dossier. Et faire mumuse avec l'URL pour taper le projet concernait. Rien de mieux a proposer
Par contre pour revenir sur les commentaires, je trouves ça bien que se soit obligatoire et encore plus avec les nouveau système distribuer. Ca sonne comme ça a mon oreille : "Autant que tu veux tu fais ce que tu veux de ton repo local mais quand viens le grand moment du pull. Tu le fais pas sans raison"
Nombre de fois dans des repo SVN que j'ai vu des commit mal foutu et 18 commit par dessus pour le corriger. Je trouve pas que se soit un geste anodin c'est bien que se soit fait avec un maximum de sécurité.
Sinon un petit site bien sympa qui explique le fonctionnement de ces système de versioning distribué et plus particulièrement mercurial
http://hginit.com/
Je peux bien mettre des URLs vers un dossier particulier de mon repo sur github pour que les utilisateurs aillent directement browser dans ce sous-dossier, mais après ils peuvent rien en fait de plus : s'ils veulent faire un checkout (enfin cloner le repo GIT) ils ne peuvent que cloner la totalité, pas qu'une sous-partie. Pareil s'ils veulent télécharger un snapshot ZIP (par exemple parce qu'ils n'ont pas de client ZIP et veulent juste récupérer mon code), ils ne peuvent que récupérer un snapshot de l'intégralité du repo.
Et c'est tout mon problème.
Alors qu'avec SVN je crois que y'a pas ce souci, puisque chaque dossier a son propre ".svn" et peut être checkouté indépendamment de la hiérarchie parente.