Quelle est la meilleure façon pour moi de commencer à utiliser le contrôle de version dans un projet opensource?


10

Il a été suggéré que je prenne mon projet open source en raison de sa taille et de mon manque de compétences, j'ai donc vérifié Google Code et commencé à créer un projet et maintenant il me demande si je veux que le projet ait Git, Mercurial ou Subversion hébergement de code.

Je ne sais même pas ce qu'est l'hébergement de code, et une recherche m'a confondu davantage avec les débats entre toutes ces choses, et cela est encore pire car Google Code me demande quel type de licence je veux.

Je pense que je ne comprends pas vraiment ce que signifie vraiment l'open source, quelqu'un peut-il à peu près faire une feuille de triche de profane rapide sur tout cela? Très appréciée.

Modifier Il y a eu beaucoup de bonnes réponses sur ces trois versions d'hébergement de code, mais je pense que je n'ai pas réussi à communiquer la vraie question: fondamentalement, je n'ai aucune idée du fonctionnement de ce code source ouvert, pourquoi devrais-je héberger le code quelque part comme ça ? Et cela signifierait-il que je dois retirer le site de mon hébergement actuel, ou s'agit-il d'un type d'hébergement entièrement différent? Que se passe-t-il lorsque je rend mon site open source, quels droits ai-je, quels droits dois-je céder? Comment ça marche, les gens viennent-ils me jeter du code gratuitement? Peut-être que ce sont des questions stupides, et si c'est le cas, alors je suppose que j'ai besoin de réponses stupides, je n'ai vraiment aucune idée de ce qu'est l'open source, sauf pour le concept de partage de code ...



c'était un diaporama génial, je pense que cela m'a aidé à saisir les bases grâce au partage, maintenant c'est le truc le plus détaillé qui me rend le moins du monde.

1
C'est vraiment 2 questions, et les deux sont probablement des doublons. stackoverflow.com/questions/2303136/… , et stackoverflow.com/questions/3859/…
sylvanaar

2
Le "manque de compétences" semble être une terrible raison de créer quelque chose d'open source. Si vous avez une idée magnifique, mais manquez de compétences techniques, alors peut-être. Je n'irais pas en open source jusqu'à ce que je trouve un partenaire techniquement qualifié qui est prêt à s'engager à produire une première coupe du code, et qui voudrait aller en open source.
tripleee

Tripleee seriez-vous en mesure de suggérer un réseau ou quelque chose de cette nature où je pourrais éventuellement trouver quelqu'un avec qui collaborer?
Nathan

Réponses:


7

pourquoi devrais-je héberger le code quelque part comme ça?

Un point clé du développement de logiciels open source est de partager le code source. Il existe plusieurs façons de procéder, comme placer des fichiers tar / zip sur un serveur Web ou ftp. Des services comme le code google (ou sourceforge.net, gitorious.org, bitbucket.org, et bien d'autres) suppriment la nécessité de faire fonctionner vos propres serveurs à cet effet.

Et cela signifierait-il que je dois retirer le site de mon hébergement actuel, ou s'agit-il d'un type d'hébergement entièrement différent?

Ces services ne sont pas des hébergeurs Web à usage général, mais exécutent des services très spécialisés. Ils ne sont pas destinés à être la page d'accueil d'un produit, mais plutôt un tableau de bord de développeur.

Avec le code Google, vous obtenez

  • un wiki
  • un bugtracker
  • espace de téléchargement de fichiers normal
  • un serveur de contrôle de version

Bien sûr, vous pouvez configurer ces logiciels sur un serveur Web standard (le contrôle de version peut être délicat, mais cela dépend beaucoup des détails), mais le principal avantage de l'utilisation d'un hébergeur de développement est que vous n'avez pas besoin de faire attention de ces systèmes pour le vôtre. Le principal inconvénient est que vous n'avez aucun contrôle sur le logiciel utilisé sur le serveur, vous devez vivre avec ce qui est disponible sur cet hôte. Vous devez également considérer ce qui se passe si le service cesse ses activités (ok, google ne tombe jamais en panne) et si vous pouvez transférer les données de l'hôte actuel vers un autre ou votre propre serveur (pensez aux sauvegardes).

Que se passe-t-il lorsque je rends mon site open source, quels sont mes droits,

C'est une question difficile, car elle dépend de la loi du pays où vous vivez.

quels droits dois-je céder.

Cela dépend de la licence que vous accordez au produit. Cela peut aller de l'open source propriétaire (pensez à PGP) où l'utilisateur ne peut fondamentalement rien faire avec le code, à l'autre extrémité de l'échelle est du domaine public, où chacun peut faire ce qu'il veut.

Comment ça marche, les gens viennent-ils me jeter du code gratuitement?

Il est très peu probable que cela se produise, car votre produit a besoin d'une popularité suffisante pour attirer d'autres développeurs.

[...] et maintenant il me demande si je veux que le projet ait un hébergement de code Git, Mercurial ou Subversion.

Il s'agit de trois systèmes de contrôle de version différents, où Subversion est centralisé, tandis que Git et Mercurial sont distribués.

Il y a des guerres de religion à propos desquelles utiliser, mais le point principal est d'en utiliser une. Voir http://martinfowler.com/bliki/VersionControlTools.html pour plus de détails.

Quand choisir Subversion:

  • Vous avez des fichiers binaires, qui ne peuvent pas être facilement fusionnés, et avez besoin du workflow lock-> modify-> commit-> unlock, que subversion prend en charge¹
  • Vous devez extraire uniquement une partie de la structure du répertoire.

¹ Il existe une extension de verrouillage pour mercurial, mais je n'en ai aucune expérience et je ne peux pas dire si elle est utilisable.

Lorsque vous n'avez pas besoin des anciennes fonctionnalités, il est préférable d'utiliser Mercurial ou Git. Les deux présentent les avantages suivants par rapport à Subversion:

  • rapide (et avec rapide je veux dire vraiment rapide )
  • branchement et fusion facile (cela s'est amélioré depuis Subversion> = 1.5, mais ce n'est pas la même chose)
  • la validation et la publication sont découplées, vous pouvez donc travailler sans perturbation sur une fonctionnalité et publier le travail une fois terminé
  • ils suivent l'état du répertoire de produits dans son ensemble
  • vous obtenez une copie complète de l'historique complet des versions lorsque vous clonez un référentiel distant
  • numéros de révision sécurisés par cryptographie, ce qui signifie que même lorsque quelqu'un pénètre dans le serveur, il ne peut pas mettre de code en place sans modifier l'historique des révisions

    • mais comme personne ne vérifie ces révisions, cette fonctionnalité n'est pratiquement pas efficace

9

L'hébergement de code est exactement cela - quelque part pour héberger (ou conserver) votre code.

Git, Mercurial et Subversion sont tous des outils de contrôle de source que vous utilisez pour gérer votre historique de code. Git et Mercurial sont des systèmes distribués tandis que Subversion est une configuration basée sur serveur plus traditionnelle.

Jetez un œil sur Wikipédia ou sur d'autres sites similaires et voyez ce qui vous plaît le plus. Personnellement, nous utilisons Mercurial et cela fonctionne très bien pour nous.


6

Joel Spolsky a écrit un excellent tutoriel sur Hg (Mercurial) et je crois que la section d'introduction couvre Subversion, y compris les raisons pour lesquelles vous passez à Mercurial. Donnez-moi une lecture, cela m'a vraiment aidé à comprendre beaucoup de choses sur Mercurial et DVCS en général.

Oh, et lorsque vous êtes prêt à héberger, vous pouvez utiliser Google Code, BitBucket , Github (à l'aide de cette excellente extension ) ou autres.


Mercurial est un excellent système, il m'a conquis de la subversion après seulement quelques minutes d'utilisation.
Jim In Texas

3

J'utilise git, que je trouve plus facile à gérer grâce au contrôle distribué. Le mercure est également bon pour cet usage particulier, mais je ne peux pas vous donner de conseils à ce sujet, car je ne l'ai jamais utilisé. SVN est un système centralisé et donc moins pratique, mais pourrait être légèrement plus simple.

L'open source signifie essentiellement que vous donnez à n'importe qui la possibilité d'utiliser votre travail et de le développer. Vous pouvez définir les limites de cette utilisation: GPL signifie que l'utilisateur doit rendre son travail ajouté open source, LGPL signifie qu'il ne le fait pas, par exemple.


2

Subversion serait l'option la plus simple car c'est un VCS. Git et Mercurial sont des systèmes DVCS. Ils sont plus modernes et plus puissants mais plus difficiles à comprendre. L'utilisation d'un frontal tel que TortoiseSVN ou TortoiseHG (pour Mercurial aka HG) est également très utile.

Si votre logiciel est un programme autonome, vous pouvez utiliser GPL ou vraiment l'ouvrir avec une licence BSD. Si votre projet est une bibliothèque que quelqu'un d'autre liera avec LGPL ou BSD; mais n'utilisez pas la GPL.

[Éditer]

En ce qui concerne votre motivation d'origine pour l'open source du logiciel: Malheureusement, le simple fait de rendre le logiciel open source ne signifie pas que vous allez obtenir un afflux de main-d'œuvre gratuite talentueuse. Il existe des centaines de milliers de projets open source. Seul un petit pourcentage d'entre eux ont des membres contributeurs actifs. Les raisons pour lesquelles ces projets réussissent ou non sont aussi variées que les raisons de la réussite et de l'échec des entreprises. Si vous voulez devenir un bon programmeur et produire de bons logiciels, vous devrez passer beaucoup de temps à apprendre, à écrire du code et à communiquer avec d'autres personnes sur des sites tels que StackOverflow.


1
Pourquoi dites-vous que svn est le plus simple? Veuillez justifier cette déclaration.

1
@ Richard: Je pense qu'il veut dire qu'il est un peu plus facile à configurer et à utiliser pour une utilisation de base, au moins je suis d'accord avec cette acceptation. Je ne suis pas d'accord avec l'idée que votre bibliothèque ne devrait pas utiliser la GPL, c'est vraiment une position politique.
Kheldar

Utilisez GPL pour une bibliothèque si vous souhaitez imposer certaines restrictions à son utilisation. Utilisez LGPL si vous souhaitez imposer moins de restrictions.
Keith Thompson

0

Il me semble que si la plupart des gens ici répondent au comment , personne n'a vraiment répondu au pourquoi dans votre question.

L'un des premiers projets open source que j'ai expérimentés a été le fabuleux projet Fractint , développé par le Stone Soup Group qui s'est inspiré de la vieille histoire populaire de la soupe de pierre .

Pour moi, cela résume mieux l'esprit de l'open source que n'importe quelle diatribe Stallman ou même le manifeste GNU original . C'est un témoignage de la force de cette communauté que Fractint est encore en développement 23 ans après que le feu a été allumé sous ce chaudron de code particulier .


0

L'open source signifie que n'importe qui peut lire, copier, modifier et distribuer votre code. Vous devez bien comprendre les implications de cela avant de continuer. Vous devriez peut-être lire un livre ou au moins parcourir les articles de Wikipédia sur le sujet et / ou http://opensource.org/ jusqu'à ce que vous sentiez que vous comprenez le concept.

(Le livre d'O'Reilly Open Sources http://oreilly.com/openbook/opensources/book/index.html est utile mais peut-être pas exactement ce que vous recherchez.)

Le système de contrôle du code source à utiliser est complètement secondaire. Vous pouvez copier / coller votre code sur une page Web et terminer. Cela dit, le contrôle de version est important, et un bon moyen pour abaisser la barre pour les développeurs. Toutes les options proposées par Google Code sont correctes; allez avec celui que vous aimez, ou peut-être reporter la question jusqu'à ce que vous puissiez demander à vos contributeurs lequel ils aimeraient utiliser.


0

Rendre votre code ou projet open source signifie que tout le monde peut le prendre et le modifier à sa guise. Cela dépend du type de licence que vous choisissez d'utiliser, mais en général, l'open source signifie que le code source est accessible à tous pour le télécharger, le modifier et l'utiliser à sa guise.

Quoi qu'il en soit, ce code doit être accessible par d'autres personnes pour l'obtenir.

Prendre votre code dans un référentiel public en ligne tel que GitHub est le meilleur moyen de le faire. Tout d'abord, votre code est désormais accessible au public. Puis, comme ces services offrent également le contrôle de version, votre code est organisé en projet. Vous pouvez suivre les modifications que vous et d'autres personnes apportez. Puisqu'il permet également de ramifier (séparer) le projet en d'autres projets différents, vous pouvez garder une trace de toutes les différentes versions que d'autres personnes ont faites de votre code.

Cela garantit également que votre code est stocké dans un endroit sûr, vous n'avez pas à vous soucier qu'il soit perdu par un disque dur défectueux sur votre PC par exemple. Et lorsque vous voulez y travailler, vous pouvez travailler de n'importe où, car votre code est en ligne, vous pouvez le trouver n'importe où.

Si vous décidez ensuite qu'il est temps de montrer votre code au monde, il suffit d'envoyer le lien vers votre référentiel de projets en ligne. C'est une technologie à laquelle les gens s'habituent, donc comme tout le monde la connaît, il est plus facile de comprendre comment la télécharger, publier des messages, créer différentes versions, etc.

C'est comme une norme commune de faire les choses, une pratique courante.

Certains liens peuvent vous être utiles pour expliquer davantage l'open source:


-6

À propos du système de contrôle de version, je dirais que vous devriez vous en tenir à l'alternative la plus utilisée et la plus récente: c'est-à-dire "Git". Mercurial est moins populaire et SVN est ancien, lent et centralisé. Avec GIT, vous bénéficierez d'un système de contrôle de version moderne et populaire. Il n'y a pratiquement rien à perdre.

Sources (regagner la popularité du DVCS):

/programming/tagged/git ~ 10k questions /programming/tagged/mercurial ~ 3k questions

http://www.googlefight.com/index.php?lang=en_GB&word1=git&word2=mercurial

11700000 résultats vs

1580000 résultats

Concernant la licence: vous devriez peut-être regarder les plus courantes: GLP, MIT, LGPL, BSD, et choisir celle qui convient le mieux à votre projet.


7
Mercurial n'est pas propriétaire ... c'est open source exactement comme Git!
Christian Specht

4
Fanboy répond avec des arguments partiellement faux.
Oben Sonne

1
"le plus utilisé" - veuillez fournir une référence à la source de ces informations.
sylvanaar

Désolé les gens .. C'est juste ma perception des choses: je suppose que Git est plus utilisé que Mercurial, et je sais que SVN est vieux, lent et centralisé ... Je me demande si vos commentaires sont moins fanboy-commentaires que mes soi-disant fanboy-answer. Allez, git hub utilise git, le noyau linux utilise git, chaque projet de mon département utilise git ...
Pedro Rolo

2
Peut-être que l'abondance de questions concernant Git illustre également qu'il est plus difficile à utiliser? Quelques personnes ont utilisé des données similaires pour enquêter sur les cadres de développement Web les plus «populaires» où le même point a été soulevé (commentant les inexactitudes).
Tim Post
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.