Hébergement de source control

Dev
1

Bonjour la zone,

Je suis en train de démarrer un petit projet avec un pote et on cherche une solution simple pour le source control. Sachant que l’on a ni l’un ni l’autre d’IP fixe ni de serveur où il serait facile de mettre en place un serveur SVN ou autre nous aimerions nous tourner vers une solution hostée.

Le problème c’est que j’ai l’impression que c’est un peu la jungle. Il existe beaucoup de solutions différentes, à des prix très différents et utilisant des technologies différentes.

L’idée serait que ce soit le moins cher possible, ça n’a pas besoin d’être ultra compliqué avec plein d’options puisque, dans un premier temps du moins, nous ne serions que deux et la solution restera simple. Après s’il y a possibilité d’avoir un systèmes de tâches ou de bug tracking je dis pas non.

Ah oui aussi, c’est pour coder en .Net sous Windows, je sais que ça peut avoir une influence.

Pour le moment j’ai retenu GitHub qui a le défaut d’utiliser Git qui n’est pas encore super pote avec Windows mais qui est bon marché et offre pas mal de fonctionnalités et Beanstalk qui utiliser Subversion mais un peu moins poussé que GitHub et un peu plus cher.

Bien entendu c’est un projet closed source (en partie en tout cas), donc ça élimine direct SourceForge et autre Codeplex.

Bref les idées et autre retour d’expérience sont les bienvenus.

Merci!

2

Subversion
Unfuddle
XP-dev
Assembla

preferences pour XP-dev et Assembla. Mais Unfuddle est bien aussi. J’ai bosse avec les 3, 3 fois content. A choisir en fct de vos besoins.

Mercurial
BitBucket
Assembla

le SCM qui monte. Tres interessant. Plutot oriente code, pas assets (plutot petits fichiers que gros fichiers de 100 mo quoi)

3

Yavait un autre super truc, mais je me souviens plus ce que c’est :smiley:
Edit: Mais en fait, c’etait pas super, le serv etait souvent down, alors j’ai switché sur codeplex.

4

(il repostera derriere quand il aura un peu cuvé son anniversaire. Quel coquin ce AnA-l) :smiley:

5

Bin pour du gratos & du SVN : google code!

6

Super, merci Ravine pour tous les liens. Je me suis lancé avec XP-Dev vu qu’ils ont une offre gratuite intéressante et qui pourrait me suffire.

Sinon, puisqu’on est dans les questions sur les source control, je suis assez impressioné par le choix de nouvelles technologies de source control qui commencent à débarquer.
Du coup, quelles sont un peu les avantages et inconvénients de chaque techno? Ente Git, Mercurial et le classique SVN (voir CVS, mais il tend à disparaître).

[quote=« AnA-l, post:3, topic: 50529 »]Yavait un autre super truc, mais je me souviens plus ce que c’est :smiley:
Edit: Mais en fait, c’etait pas super, le serv etait souvent down, alors j’ai switché sur codeplex.[/quote]

Uhuh, merci AnA-l, ça ne m’a pas beaucoup aidé mais au moins ça m’a bien fait poiler :smiley:

LeGzo : J’ai bien précisé que c’était pour faire du closed source. Google Code est fait, à ma connaissance, uniquement pour les projets open source, tout comme SourceForge et CodePlex. Donc c’est inutile pour moi.

7

Si tu as eu l’occasion de bosser un peu avec Perforce, Mercurial s’en rapproche un peu dans le principe. En gros, tu commit de facon locale des changesets. Chaque commit et purement local. C’est a la synchronization avec le serveur que tu vas envoyer tous tes changesets dans ton repository.

SVN est plus direct. Chaque check dans ton SCM est une revision, et se fait en direct avec ton repository.

Apres y’a d’autres subtilite, mais comme je comprends pas tout, je prefere me tenir au “ca fonctionne”, et continuer a les utiliser avec le sourire.

8

Git/Mercurial/Bazaar/Darcs c’est un peu la même popote, c’est du contrôle de version décentralisé, ou on peut ne pas avoir besoin de serveur centralisé, dans la théorie, dans la pratique c’est quand même mieux d’en avoir un.

Ce qu’ils apportent par rapport au classique SVN/CVS (die CVS die, nous ne le répeterons jamais assez), c’est une souplesse inégalé pour la gestion des branches. La branche ne se voit plus comme un élément figé “oh mon dieux c’est dans /branches de SVN ça fait peur” à “bon bah j’ai une tache, jme fait une branche pour pas casser l’état propre et je ferait un merge après”. De plus il y a un nouveau niveau dans la gestion de donnée, le commit se fait sur ta copie locale du dépôt et un push envoi les les nouvelles données pour les branches communes au serveur distant (faut s’y faire un peu à celui là).

Donc joie, on peut travailler, commiter, pusher & parcourir le log en étant déconnecté du serveur. Le fait que tout soit en local file un sacré boost en performances également, le commit en 0.01s, c’est toujours agréable, surtout si on commit plusieurs fois avant d’envoyer toutes les modificatoins au serveur.

Pour parler de ceux que j’ai utilisé plus ou moins brièvement :
[ul]
[li]Darcs : on oublie, supporte mal la charge, très peu utilisé en dehors du monde des haskelleur[/li][li]Bazaar : réalisé en python, possède une Gui qui fonctionne sous windows, mais aux traductions douteuses. Version en ligne de commande parfaitement utilisable.[/li][li]Git : Pour moi c’est la star du moment, rapide, mais TortoiseGit encore jeune sous windows et des commandes au nom étrange pour pas grand chose *, pas forcément intuitif en ligne de commande. Fonctionne bien sous Windows (version MingW/Msys)[/li][/ul]
Ma préférence va pour git, parce que je le connais bien, mais basiquement, t’en connais un, tu peux switcher avec n’importe quel autre rapidement. Par contre il faut prévoir une petite semaine d’adaptation en venant de svn/cvs pour bien prendre le plis.

Pour les désavantages, ben c’est plus compliqué, ça peut partir dans tous les sens, et pour pousser des non-techniciens à utiliser les systèmes distribués (même avec une interface), c’est pas gagné. Les outils autours sont aussi plus jeunes et moins bien paufinés que toute la gamme d’outil pour SVN par exemple, il y a moins d’hébergeur également. Un autre problème également, sous git, on perd le numéro de révision au profit d’un hash SHA-1, wouuh génial, on peut pas falsifier un commit, mais pas pratique pour remonter dans le temps facilement, heureusement il existe une interface minimaliste pour aider à retrouver la bonne révision. Et quand on maitrise pas, on peut facilement recréer un métro au niveau des branches :

(quand on se limite, c’est moins porky quand même)

  • oui je pense à vous git push master:/ref/origin/master et git push :/ref/origin/master (pour ajouter et supprimer une branche lointaine, respectivement)
    Ce post vous a été offert par l’association des anglicisme anonymes.
9

Ultra intéressant, merci de l’explication !

10

@Twinside : Si tu kiffes bien Git, je t’invite a checker du cote de Mercurial, il se pourrait que ce dernier t’interesse aussi. C’est du meme monde. Je ne connais pas Git, mais j’utilise un peu Mercurial cette annee, j’avoue qu’apres quelques temps d’adaptation (venant de SVN), c’est passe tout seul.

(avec en plus TortoiseHG pour jouer du clic-clic, c’est encore mieux)

11

Ah yes, j’ai du lire un peu vite. En même temps je me demandais pourquoi personne n’avait cité googlecode, ça me semblait bizarre aussi!

12

Et puis avec git (je crois que Mercurial a des fonctions équivalentes), une fois qu’on a pris goût à faire des trucs du genre réécrire l’historique avec rebase -i (afin d’avoir une liste de commits propre à pusher), ou bien chercher un bug avec bisect, c’est difficile de revenir à svn :smiley:

C’est vrai que les commandes de git sont un peu cryptiques mais on s’habitue. J’ai aussi essayé Mercurial mais je l’avais trouvé trop lent à mon goût.
Et enfin github est un excellent hébergeur, non seulement pour ses fonctionnalités mais aussi grâce au nombre de personnes dessus et ainsi au côté social.

13

Ravine > Yep je connais de nom, mais j’avoue avoir la flemme de changer de système de contrôle de version pour le moment, on verra pour les prochains projets.

Je profite de ce thread pour faire remonter un outil assez marrant trouvé sur Gamedev.net : Gource. Visualisation de la mort qui tue pour GIT, Mercurial, SVN et CVS.

14

Tiens, pendant que les gens comparent un peu les source controls, j’en profite pour poser une question a propos de Git: est-ce qu’il est “granulaire” au niveau fichier ou repertoire?
Je m’explique: SVN est granulaire au niveau repertoire. Tu checkout un repertoire entier ou pas du tout. Perforce, par contre, est granulaire au niveau fichier. Tu peux faire un sync d’un fichier tout seul dans un repertoire contenant plein d’autres fichiers (un corollaire est qu’on peut creer des repertoires vides sous SVN, mais pas sous Perforce).

Je voudrais savoir parce qu’a la maison, j’utilise du source control pour autre chose que du code (e.g. fichiers photoshop et autres), et ces autres choses sont souvent des gros fichiers. Ca veut dire que je veux souvent faire un sync/checkout d’une partie seulement du truc. Donc avec SVN, ca me force a “partitionner” mes fichiers dans plusieurs repertoires… d’ou ma question: quelle est la granularite de Git?

15

[quote=« lordabdul, post:14, topic: 50529 »]Tiens, pendant que les gens comparent un peu les source controls, j’en profite pour poser une question a propos de Git: est-ce qu’il est « granulaire » au niveau fichier ou repertoire?
Je m’explique: SVN est granulaire au niveau repertoire. Tu checkout un repertoire entier ou pas du tout. Perforce, par contre, est granulaire au niveau fichier. Tu peux faire un sync d’un fichier tout seul dans un repertoire contenant plein d’autres fichiers (un corollaire est qu’on peut creer des repertoires vides sous SVN, mais pas sous Perforce).

Je voudrais savoir parce qu’a la maison, j’utilise du source control pour autre chose que du code (e.g. fichiers photoshop et autres), et ces autres choses sont souvent des gros fichiers. Ca veut dire que je veux souvent faire un sync/checkout d’une partie seulement du truc. Donc avec SVN, ca me force a « partitionner » mes fichiers dans plusieurs repertoires… d’ou ma question: quelle est la granularite de Git?[/quote]
La granularité de git c’est le repository :smiley: On peut contourner en utilisant les submodules, mais par défaut si tu as un seul repository, tu ne peux faire qu’un checkout complet, idem pour update.

16

Ah merde. Bon ben c’est mort pour quoique ce soit d’autre que des purs projets de code. Merci.

17

Je pige pas tres bien ton souci avec svn. Tu peux tres bien commit un fichier seul dans un repertoire, sans aucun soucis. Par contre, il faut effectivement que tout ton folder soit versionné, si c’est ca que tu voulais dire.

18

Oui, plus ou moins… Genre si dans ton repository t’as un repertoire avec 10 fichiers Photoshop de 300Mb chacun, plus 1 fichier texte de 1kb, tu dois tous les recuperer (et ici, je parle bien du checkout, hein, pas du update, meme si c’est le meme probleme). Si tu veux juste travailler sur le fichier texte sans depenser 3Gb d’espace disque, il faut mettre le fichier texte dans un repertoire different pour pouvoir faire un checkout partiel.
Ca devient important quand tu veux pouvoir bosser sur le fichier texte depuis un netbook, ou quand t’utilises differents OS et que du coup tout une partie du repository n’a pas forcement de sens (e.g. des fichiers Photoshop sous Linux).

19

Ok, c’est dans ce sens la que ca te posait souci, donc oui, /agree :smiley: