Nous avons une image VMware exécutant un instance GFORGE sur notre réseau local. Nous voudrions que certains folks externes font partie du processus de développement. Nous aimerions conserver ce référentiel en tant que référentiel principal SVN. Quels types d'options sont disponibles pour partager le code avec les ressources externes et la fusionner dans notre référentiel local.
D'autres options pourraient être d'accueillir cela entièrement en dehors de notre réseau (sur certains des fournisseurs d'hébergement), ce n'est pas acceptable car il permet aux employés d'accéder au code en dehors de notre réseau.
Je cherche des suggestions pour résoudre ce problème.
5 Réponses :
svn n'est pas un VCS distribué. Si vous voulez coller avec SVN, vous n'aurez aucune alternative réelle que de leur donner accès à votre serveur local de l'extérieur d'une manière ou d'une autre.
Si vous voulez qu'ils puissent vous engager dans un repo externe séparé, qui n'est pas connecté physiquement à votre serveur interne et de fusionner leurs modifications dans le référentiel central manuellement, vous devrez regarder un VCS distribué comme < un href = "http://git-scm.com/" rel = "nOfollow noreferrer"> git ou Mercurial .
Subversion est un système de contrôle de version centralisé (vs distribué). Il est conçu pour permettre la collaboration en effectuant des opérations simultanées contre le seul et unique référentiel. Donc, vous avez essentiellement deux options:
Quelque chose d'autre serait une solution de contournement compliquée.
Une considération importante pour vous devrait être:
Si vous regardez les développeurs travaillant et commettant les changements qu'ils apportent à leur code régulièrement - alors SVN est bon.
Si vous envisagez des développeurs qui vont travailler sur de gros morceaux sur eux-mêmes et que vous souhaitez fusionner leur codeBase une fois qu'ils sont sûrs de l'intégrité des choses qu'ils ont travaillé - aller avec git ou mercuriale.
J'aimerais aussi ajouter que GIT peut faire un bon bon travail, même avec une intégration continue, cependant, si vos développeurs sont plus familiers avec les outils basés sur SVN, il pourrait ne pas être que utile engager la surcharge de leur faire apprendre un nouvel outil.
Un référentiel VCS distinct (Git, Mercurial, bazar) pourrait avoir des crochets qui envoient des correctifs à un portier (personne avec accès SVN) pour intégrer des contributions de développeurs distribuées.
Les crochets de mise à jour / cloner / checkout sur les VC distribués pourraient également mettre à jour / tirez / fusionner à partir du repo SVN, en conservant vos VC distribuées synchronisées avec SVN.
Cette approche maintiendrait votre processus SVN Server et Workflow et de sauvegarde qui fonctionne pour vous maintenant. Seuls les nouveaux développeurs distribués doivent apprendre une nouvelle VCS (bazar, git, etc.).
Je dois le faire sur un projet maintenant et mettra à jour avec des détails.