Passage de SVN à & # 8230 ;?

Question

Je travaille actuellement dans une équipe au sein de laquelle nous "utilisons" " un référentiel de subversion. Je dis "en utilisant", car en réalité, tout le monde édite des fichiers directement sur un serveur via des partages samba, tandis que de temps en temps notre architecte effectue une validation de ce serveur avec nos modifications, qui sont ensuite transmises à des serveurs.

Nous sommes donc en train de manquer la possibilité de recevoir des messages de validation significatifs de différents utilisateurs et de pouvoir les utiliser aussi souvent que nous le souhaitons.

J'ai essayé de susciter un certain intérêt pour les systèmes distribués, et comment le flux de travail que nous avons actuellement semble pouvoir être très bien configuré avec quelque chose comme git (nous nous engageons sur nos machines locales puis nous le poussons examen) mais je ne pense pas que j’ai assez d’expérience avec git. La plupart de mes expériences DVCS ont été avec mercurial.

Chacun travaille à peu près dans un environnement Windows en utilisant tortoisesvn, et c'est comme cela qu'ils sont habitués à interagir avec le système, mais ils utilisent parfois PuTTY pour travailler sur l'un des serveurs linux et savent comment faire une ligne de commande. commettre.

Quelle est la voie à suivre avec cela, j'ai vu une partie du travail effectué pour créer des passerelles entre SVN et certains DVCSE, est-ce que quelqu'un a déjà une expérience de la configuration et du travail dans un tel environnement?

Qu'en est-il des migrations à grande échelle d'un SVN vers un DVCS?

Answer 1

Si votre équipe ne comprend pas bien comment utiliser la subversion, je ne sais pas comment vous allez pouvoir la faire comprendre à git. D'autant plus qu'ils sont dans la mentalité de "permet à tous de travailler dans la même copie de travail". ils vont avoir du mal à saisir un système de contrôle de version distribué.

D'après mon expérience, pour utiliser svn-git, vous devez savoir comment utiliser git ET vous devez savoir comment utiliser svn. Je recommanderais de leur apprendre à utiliser svn correctement.

Answer 2

Y a-t-il une raison pour laquelle vous ne souhaitez pas simplement conserver votre référentiel SVN et l'utiliser de la manière dont il est destiné à être utilisé?

Pourquoi ne pas demander à tout le monde d’enregistrer et de fusionner, d’utiliser des branches, etc.? Pourquoi changer si vous avez une configuration de référentiel?

Answer 3

Il semble que le problème que vous décrivez concerne principalement les procédures et protocoles appropriés pour le code de validation. obtenir un produit différent ne changerait pas la façon dont les gens travaillent. vous devez d'abord les éduquer. montrez-leur comment mieux faire les choses.

Sur une note différente, je n’ai pas compris comment vous utilisez tortoiceCVS pour l’interfaçage avec SVN.

Answer 4

Pour moi, il semble que le choix d’un système de contrôle de version ne soit pas le problème. Ce que vous devez faire, c'est convaincre l’architecte de la nécessité de définir des règles rationnelles pour utiliser un système de contrôle des versions.

Votre système svn actuel conviendrait parfaitement; Laissez les utilisateurs créer des branches si vous devez garder le coffre propre. L’architecte peut les fusionner selon ses besoins.

Maintenant, vous pouvez déplacer un DVCS et il y a de bonnes raisons de le faire. Mais si l'équipe n'est pas habituée à utiliser un serveur / client, cela peut s'avérer difficile. Et vous pourriez utiliser git ou hg localement, mais ce sont des solutions de contournement à une utilisation de rcs fondamentalement cassée. Demander à tout le monde d’utiliser svn d’abord serait ma suggestion.

Édition de fichiers sur un partage Samba ?? Sérieusement?!

Answer 5

git-svn est définitivement votre meilleur pari ici. Vous pourrez utiliser toutes les fonctionnalités locales de contrôle de version et de révision des modifications de git, mais vous pourrez en fin de compte utiliser l'option "final". enregistrements dans votre référentiel svn existant.

Ceci a pour effet génial de laisser votre équipe se mouiller un peu à la fois avec git (à la fois parce que vous pouvez essayer avant d'acheter et parce que vous pouvez toujours utilisez tous les processus de déploiement / maintenance que vous avez développés avec SVN).

Il existe également un cours intensif sur la syntaxe git pour les utilisateurs de svn que vous pouvez utiliser pour mettre votre équipe au courant.

Answer 6

Votre problème n'est pas SVN, mais ne l'utilise pas correctement.

Answer 7

Comme Steve Yegge pourrait le dire: TOOOOOLS

Comme d'autres le disent, si vous ne pouvez pas les amener à utiliser svn, ils n'utiliseront pas de vcs distribués.

Utilisent-ils des IDE? Si tel est le cas, recherchez des plugins pour l'EDI qui facilitent l'utilisation de svn. Ils peuvent donc cliquer avec le bouton droit de la souris sur un fichier ou un dossier de l'EDI et l'archiver. Si vous facilitez l'utilisation du contrôle de source sur une copie locale plutôt que d'accéder directement aux fichiers centraux, vous aurez peut-être une chance. Ensuite, vous pouvez utiliser TortoiseSVN pour des tâches plus complexes.

Quelques liens vers des plugins SVN pour les IDE populaires afin de vous aider à démarrer:

• Visual Studio - AnkhSVN et VisualSVN
• Eclipse - Subversive et Sous-clip
• Netbeans - Subversion

Et voici une liste des plug-ins créés à partir du site Web Subversion.

Answer 8

hg est également assez doué pour travailler avec subversion - voir https: // www. mercurial-scm.org/wiki/WorkingWithSubversion . L'équipe de développement principale de Python vient de décider de passer de Subversion à Mercurial (après une longue période de discussion où git et bazaar ont également été pris en compte); dans un développement indépendant, le service d'hébergement gratuit de code.google.com pour les projets open-source a ajouté la prise en charge de hg à la prise en charge de longue date de svn.

Answer 9

git et bazar supportent bien svn. En fait, git-svn a beaucoup mûri au cours des derniers mois.

essayez git, car un DVCS est vraiment sympa, et aussi difficile que cela puisse paraître.