Mauvaise utilisation de SVN - Mercurial est-il la réponse?


13

Au travail, nous utilisons SVN, mais uniquement de nom. Nous ne branchons ni ne fusionnons. Nous gardons deux copies du référentiel, une servant de branche "tag" qui est copiée lorsque nous faisons un déploiement et conservée pour les corrections de bugs et immédiate "ceci doit être mis en ligne dès que possible". Nous devons nous rappeler de copier les modifications apportées dans une copie à l'autre copie (le "tronc"). Nous avons une douzaine de projets dans un seul dossier dans le référentiel, au lieu de les séparer. En bref, la seule chose pour laquelle nous utilisons SVN est de pouvoir valider. Tout le reste se fait manuellement.

J'ai évalué Mercurial; J'ai utilisé Git dans le passé (je suis le seul de l'équipe à avoir utilisé un DVCS) et je prends Mercurial rapidement. Je suis en train de débattre de l'introduction de Mercurial au reste de l'équipe comme une "meilleure façon" de faire les choses parce que la ramification est un jeu d'enfant, la fusion est beaucoup plus facile, et nous pouvons valider les choses localement au contenu de notre cœur et les pousser uniquement vers le centre branche quand ils sont prêts. Nous obtiendrions tous les avantages de SVN (et nous n'obtenons pas beaucoup d'avantages de toute façon puisque personne ne comprend vraiment SVN), plus pour les nouvelles fonctionnalités, nous n'avons pas besoin d'avoir des tonnes de fichiers non versionnés flottant, donc si nous devons revenir en arrière Nous sommes foutus. Le workflow semble un peu plus simple - nous devons juste nous rappeler que "Commit" est local et "Push" est comme le commit de SVN,

Est-ce une bonne approche à adopter? Gardez à l'esprit que l'équipe est très flexible et acceptera tout ce qui améliorera notre qualité de travail et facilitera la façon dont nous faisons les choses - le CIO m'a même demandé quand j'ai mentionné comment nous n'utilisions pas SVN à son potentiel " y a-t-il quelque chose de mieux que nous pouvons utiliser? " il est donc à bord avec elle aussi.


13
HgInit - Cela commence par la rééducation subversion, que je pense que vous trouverez utile.
yannis

20
N'avez-vous pas peur qu'ils finissent également par mal utiliser le Hg?
Odé

6
Je pense qu'un DVCS serait une horrible idée pour votre situation, car la courbe d'apprentissage est plus élevée et vous, en tant qu'organisation, avez du mal à utiliser les fonctionnalités de base de SVN. Le passage au DVCS ne devrait se produire qu'après avoir utilisé des balises, une organisation appropriée du référentiel et des techniques de fusion appropriées dans SVN et constaté qu'il fait toujours défaut pour vos besoins.
maple_shaft

2
@WayneM Choisir d'utiliser SVN sur un DVCS n'est pas forcément une erreur. Certaines personnes (moi y compris) n'ont aucun problème avec la fusion dans SVN et trouvent que la complexité supplémentaire de DVCS l'emporte sur les avantages perçus, surtout si vous êtes une petite équipe localisée. Je ne prendrai probablement pas le DVCS très au sérieux jusqu'à ce que je me retrouve dans une grande équipe de développement où la fusion est un énorme problème.
maple_shaft

4
@maple_shaft I will probably not take DVCS very seriously until I end up on a large development teamOu jusqu'à ce que vous vous retrouviez dans une équipe distribuée. Nous sommes une petite équipe (5 personnes) travaillant sur 3 sites (et parfois 5, quand nous n'avons pas envie de sortir du lit), et le passage de svn à hg était le bienvenu ...
yannis

Réponses:


15

Oui.

Si vous remplacez "SVN" par "Perforce" dans votre OP, vous avez à peu près la situation dans laquelle je me suis retrouvé lorsque j'ai commencé mon travail actuel, même jusqu'à la copie à changement manuel. Deux ans plus tard, nous sommes sur Mercurial et tout le monde convient que cela a été un grand changement.

Nous avons la possibilité de créer des branches et de fusionner par cas de support , ce qui est incroyablement utile pour le contrôle qualité, et la possibilité de créer un nombre illimité de branches et de référentiels jetables à tout moment, que nous pouvons ensuite créer et vérifier dans notre serveur CI, puis déployer à un environnement de test cloud et vérifier la fonctionnalité. Cela a été extrêmement bénéfique en termes de tranquillité d'esprit: lorsque nous effectuons un déploiement en direct, nous sommes presque sûrs à 100% que cela fonctionnera (sans environnement / problèmes de base de données, qui sont évidemment hors de portée du VCS).

Fondamentalement, ce que nous avons gagné en passant au mercure est de respirer de l'espace. Nous n'avons plus à nous soucier du coût d'une agence ou des horribles sessions de fusion qui suivaient inévitablement, tout est beaucoup plus facile. Nous utilisons également FogBugz assez fortement, donc le lien avec Kiln (leur mercurial hébergé) est vraiment utile.

Le commentaire sur le site hginit est également clair , comme un aperçu d'un flux de travail de contrôle de version qui fonctionne réellement (en supposant que vous l'ajustiez pour le flux de travail QA particulier de votre entreprise).

Le seul défaut possible dans les contrôles de version en mouvement est que vous aurez besoin de quelqu'un qui est vraiment une force motrice derrière le changement, qui est heureux de lire sur le sujet et d'utiliser vraiment l'outillage au mieux de son potentiel, ce que vous semblez vouloir faire.

Je ne suis pas d'accord non plus avec les commentaires sur la taille de l'équipe et la répartition des équipes concernant l'utilisation de DCVS. Il s'agit vraiment de la distribution de CODE. Si vous avez plusieurs cycles de développement se déroulant en parallèle, soit des cas de support sur un système hérité, soit un tas de fonctionnalités ou même de nouveaux systèmes (ce que vous en pensez), vous bénéficierez de l'utilisation d'un DVCS.


3
-1, si les développeurs ont déjà de tels problèmes avec Subversion, il est extrêmement peu probable qu'ils "obtiennent" un système plus complexe. La bonne réponse est, comme le disent les commentaires sur la question, une rééducation du fonctionnement de Subversion (et VCS en général) ...
Izkata

1
@EdWoodcock, je pense que ce que vous avez observé pourrait être dû au fait que votre équipe a commencé avec une "table rase". Le changement complet de VCS en mercurial signifiait que tout le monde devait recommencer à zéro et ne pouvait plus dépendre des mauvaises habitudes qu'il utilisait dans SVN. Souvent, il est plus facile de surmonter les mauvaises habitudes en "recommençant" dans un autre contexte (dans ce cas, mercuriel).
Angelo

2
@EdWoodcock: Perforce peut avoir la pire branche de tous les VCS encore en usage. Le branchement dans SVN est beaucoup plus facile.
kevin cline

1
Quel que soit le système de contrôle de version utilisé, je pense qu'il est important de "fixer les règles" et de passer du temps à passer en revue tous les scénarios d'utilisation avec votre équipe. Les gens ne sont pas nés en sachant comment faire des branches, des balises et des enregistrements, différentes équipes font ces choses de différentes manières et les systèmes VCS n'appliquent pas un flux de travail sur un autre. Si les membres de l'équipe ne sont pas tous sur la même page en termes d'attentes et d'utilisation, le contrôle de version devient un cauchemar. Ce sont des problèmes communs à TOUS les systèmes VCS.
Angelo

1
@ChrisS Cette parabole est plus applicable à un VCS standard où il y a un coût de branchement. De plus, il s'agit de ramifier, de valider, puis de fusionner à nouveau, ce que <i> vous faites chaque fois que vous clonez </i> dans un DVCS. De plus, je viens de vous expliquer pourquoi l'approche fonctionne vraiment pour nous; être dogmatique sur la méthodologie est assez idiot.
Ed James

21

Un autre outil ne va probablement pas résoudre votre problème, je dirais que vous devriez lire cet article, je l'ai trouvé très utile:

http://thedailywtf.com/Articles/Source-Control-Done-Right.aspx

Je pense que le point principal de l'article est résumé ici, mais veuillez le lire:

En fin de compte: pas vraiment sur les outils

Pendant tout le temps que j'ai passé à travailler avec et à intégrer différents systèmes de contrôle de source, je suis arrivé à une conclusion: ce n'est pas l'outil, c'est la façon dont vous l'utilisez. C'est une déclaration terriblement galvaudée, mais cela semble particulièrement vrai ici. Lorsqu'il est utilisé pour gérer correctement les modifications du code source - étiquetage des builds, branchement par exception, etc. - même le système de contrôle de source le plus léger (* cough * SourceSafe * cough *) surpassera de loin une configuration Mercurial avec un tas de validations aléatoires et pousse.


6
+1, il ne s'agit vraiment pas des outils. SVN est parfaitement capable, comme c'est forcément.
Angelo

1
Il s'agit de personnes, pas d'outils. J'ai vu des projets bien gérés utilisant toujours le système de versions simultanées pour le contrôle de version, ainsi que des projets terribles exécutant GIT ou Mercurial ..
Alexander Galkin

Il ne s'agit pas vraiment d'outils, à moins que vous n'en ayez de meilleurs pour complimenter le fournisseur de contrôle de source comme github, bitbucket
Chris S

3
Bien que je convienne que c'est la façon dont vous utilisez vos outils qui compte, il est également vrai que différents outils vous conduisent dans des directions différentes. Des outils comme Mercurial vous mènent sur une voie de simplicité et de flexibilité. Git vous mène sur un chemin de complexité mais de flexibilité extrême, Subversion rend certaines choses plus faciles que d'autres, donc vous éloigne des choses difficiles et délicates, tandis que Visual Sourcesafe vous mène sur un chemin d'extrême inflexibilité et de frustration de tête. * 8 ')
Mark Booth

10

Non. La technologie résout rarement ce genre de problème.

Mercurial est plus complexe que Subversion (oui, la ramification et la fusion sont meilleures et peut-être plus faciles, mais le modèle de Subversion est beaucoup plus simple que celui de Mercurial). Si vous utilisez Subversion de manière aussi braindead, vous pourriez finir par utiliser Mercurial:

  • a) De manière adéquate ou meilleure
  • b) Insuffisant, mais meilleur que votre utilisation actuelle de Subversion
  • c) Aussi insuffisamment que maintenant
  • d) Pire que maintenant

c) et d) sonnent comme les résultats les plus probables. Notez pourquoi vous pensez que vous vous retrouverez en a) ou b).


5

Je ne peux pas parler du fonctionnement des grandes équipes, mais pour les petites équipes, beaucoup de ces gros problèmes SVN ne sont pas vraiment des problèmes SVN ... Ce sont des problèmes de développement. Si vous ne suivez pas les normes de développement modernes (le plus important est de faire une intégration continue), le versioning devient le gâchis exact que vous décrivez ... Avant de passer à un nouveau système, assurez-vous d'effectuer une véritable analyse des causes profondes de votre problème ...


3

Non. Les outils ne remplacent pas la méthodologie.

Si vous n'utilisez pas Subversion comme SCM , vous ne pouvez pas utiliser Mercurial également (et cela se produira probablement)


2

SVN peut faire ce que vous en avez besoin et il n'est pas nécessaire de changer de cheval à mi-parcours pour un gain douteux.

Quoi que vous fassiez, vous devrez surmonter un problème de confiance. Quelqu'un doit être en mesure de convaincre tout le monde de modifier son flux de travail. Ce n'est pas facile, même dans les meilleures circonstances, même si vous avez de la logique et des faits de votre côté. C'est l'une des choses les plus difficiles à faire dans une organisation. Si vous la bâcler ou si elle devient difficile, vous perdez confiance et il sera très difficile de regagner cette confiance.

Il y a deux ou trois choses que je sais que les gens ont essayées avec succès. Peut-être que l'un d'entre eux fonctionnera pour votre équipe:

  1. Amenez un "coach" pour fournir une série d'ateliers pour l'équipe. Il devra probablement s'agir d'une personne externe (ironiquement, il est souvent plus facile pour de nombreuses équipes de faire confiance à un étranger que de faire confiance à quelqu'un de l'équipe). Il doit s'agir de quelqu'un qui connaît ses affaires de fond en comble et qui peut effectivement enseigner ces compétences à des personnes à tous les niveaux de compréhension et élaborer un plan pragmatique pour déployer le nouveau VCS (*) dans le flux de travail de l'équipe.

  2. Démarrez un projet "skunk-works" pour tester et valider le nouveau VCS sur un petit projet parallèle. Choisissez quelques développeurs "alpha" qui sont prêts à essayer de nouvelles choses et ne craignez pas d'accumuler un tas d'expériences infructueuses. Lorsque le skunk-works est en mesure de démontrer des améliorations irréfutables CONCRETES dans le flux de travail, vous pouvez alors essayer de le déployer au reste de l'équipe et vous avez quelques évangélistes pour vous aider à le faire.

(*) par "nouveau VCS" je ne veux pas nécessairement dire mercurial ou git, il peut aussi être SVN (bien fait).

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.