Mon entreprise gère SVN en ce moment et nous le connaissons très bien. Cependant, parce que nous faisons beaucoup de développement concomitant, la fustion peut devenir très compliquée. Nous avons joué avec HG et nous aiment vraiment la capacité de faire des clones rapides et efficaces sur une base par caractéristique.
Nous avons deux problèmes principaux que nous aimerions résoudre avant de passer à HG:
Conseil reçu avec gratitude. Rory
4 Réponses :
Suggestion: examinez également GIT.
Avec tout système de contrôle de version distribué comme HG ou GIT, votre copie locale du représentant contient à la fois les fichiers de travail et le référentiel local. Cela peut être toute la sauvegarde que vous voulez. Si vous avez besoin de plus, copiez simplement les fichiers (y compris les fichiers de repo dans le répertoire .HG ou .git) à votre emplacement de sauvegarde.
Merci pour votre commentaire. Une sauvegarde basée sur un fichier signifie toutefois que le clone local et les travaux associés sont alors à l'extérieur du référentiel serveur de notre équipe. Ce n'est pas ce que nous voulons.
Je ne peux pas parler à votre problème de migration de branche SVN. Votre solution sonne bien, mais la concurrence est très très difficile, et je n'ai pas pensé à votre situation assez bien pour dire.
Mais en supposant que vous effectuez un référentiel séparé sur le serveur pour chaque «branche SVN», je pense que vous pouvez résoudre votre deuxième problème très facilement. Premièrement, suivez Le conseil de Peter Loron en copiant les fichiers à travailler. Ensuite, chaque fois qu'un développeur est prêt à s'engager à «le référentiel basé sur le serveur de notre équipe» *, ils peuvent alors s'engager, tout comme une «branche HG-HG»: dans le même référentiel même. Vous obtiendrez le même type de commits de «commit intérimaire: la fonction DB ne fonctionne pas encore» mais ils ne seront pas sur le coffre qui vissait la construction de tout le monde.
La clé de tout cela fonctionne, et la raison pour laquelle Hg / Git est si cool, c'est que lorsque la fonctionnalité est effectivement effectuée, vous fusionnez que "HG-branche" est de retour dans le coffre dans le même référentiel et les chances sont bien meilleurs qu'avec SVN que la fusion automatisée fonctionnera simplement.
Je suis inquiet, cependant, que la fusion les changements et la suite de l'historique peuvent devenir difficile entre les branches dans ce modèle.
Eh bien, vous avez décidé de garder des succursales dans des clones séparés et que cela ne vient pas gratuitement. Mais ce n'est pas un gros problème pour définir un fichier de configuration de niveau de référentiel qui alias tous les clones pour faciliter la mise en place / la traction.
Si les programmeurs de notre équipe font localement clones d'une branche, comment sont-ils sauvegardes le clone local? Nous sommes habitués à voir svn commettre des messages comme celui-ci sur un Branche de fonctionnalités "COMMIT INTERMEN: DB fonctionne pas encore fonctionne ". Je ne peux pas voir une façon de le faire facilement dans HG.
C'est la raison numéro une des raisons pour utiliser un DVCS car il prend en charge ce cas d'utilisation parfaitement. Les engagements sont locaux jusqu'à ce que vous les poussez. Cela signifie que chaque développeur peut créer autant de "intérims" comme il voit en forme. Mais ce n'est pas une "sauvegarde" dans le sens original, c'est plus comme un "point de sauvegarde" pour le développeur individuel. Jusqu'à présent, vous avez encombré votre histoire avec ces intérimaires commettant qui ont été partagés à tous les développeurs de votre équipe. En utilisant des files d'attente mercuriales, vous pouvez facilement "plier" tous ces intérêts s'engagent ensemble avant de les pousser, conduisant à une histoire propre dans votre référentiel central.
Si la vraie sauvegarde (dans le sens de: Que se passe-t-il si cette machine de développement capte le feu) est une préoccupation que la réponse est simple: donnez à chaque développeur un référentiel de serveurs privé où il peut continuer à appuyer régulièrement.
Mon équipe travaille activement dans HG maintenant. Nous avons constaté que nous vous engageons davantage, des engagements plus petits que dans SVN, et nous avons découvert que nous allons les pousser à la repo central. Nous faisons également des courriels réguliers de patchs résumant des ensembles de correctifs; Une merveilleuse façon de se tenir au courant du travail de quelqu'un d'autre.
Si vous avez besoin de beaucoup de développement concomitant, vous devez utiliser un système de contrôle de version distribué, ClearCase ou Perforce. ClearCase and Perforce Ne faites pas de contrôle de version distribuée, mais ils gèrent les fonts probablement mieux que la plupart des autres outils là-bas.
La fusion de Clearcase est faite pour le développement concomitant et fonctionne extrêmement bien. En fait, la plupart des développeurs de Clearcase se développent sur leur propre branche, puis fusionnent leurs modifications dans le flux d'intégration lorsque ce qui travaillent est complet. La couche UCM au-dessus de ClearCase automatise simplement ce comportement.
La fusion de Perforce est plus adaptée à ce qu'ils appellent Divergent Branching , mais il semble gérer le développement simultané d'accord.
Subversion est un système de contrôle de la version agréable. Je l'utilise beaucoup, et vous ne pouvez pas battre le prix, mais nous allons faire face à cela, la fusion de subversion est toujours très, très rugueuse autour des bords. L'utilisation de propriétés pour suivre la fusion est très pirate. Lorsque vous examinez des journaux, vous voyez de nombreux modifications simplement dus à la modification de la variation de SVN: Fusionner la propriété même si les fichiers étaient fondamentalement non affectés. De plus, vous devez savoir quand utiliser le drapeau --Reintégrate.
Bien sûr, les systèmes de contrôle de la version distribués gèrent le développement simultané avec Aplomb. C'est la façon dont ils ont été conçus dès le début.
Ma seule question est pourquoi faites-vous tellement de développement simultané? Au fil des ans, j'ai trouvé forçant les développeurs à travailler ensemble sur le même ensemble de changements fonctionne simplement le meilleur. Lorsqu'ils sont forcés de travailler sur le même ensemble de code, les développeurs sont plus prudents avec leur développement. Ils prennent des morsures sont plus prudentes des changements et communiquent davantage les uns avec les autres.
Quand je travaillais avec des développeurs à Clearcase et que chaque développeur avait sa propre branche, j'avais l'habitude de faire le tour et de faire en sorte que les développeurs fusionnaient régulièrement leurs changements. Il est tellement plus facile de programmer quand personne, mais vous changez le code. Les développeurs feraient simplement tout leur travail sur leur branche sans que les changements avaient apportés. Vous avez 20 développeurs tout cela, et vous ne voyez aucun changement sur la branche principale. Ensuite, juste avant de recevoir une livraison, les développeurs feraient ensuite des fantasmes massifs de tous leurs changements. Hilarité s'ensuivit.
Nous passerons la semaine prochaine à essayer de tout nettoyer et de faire appel à tous les changements du développeur pour travailler ensemble. QA était contrarié parce qu'ils n'avaient presque pas de temps pour tester. Il n'était pas rare d'envoyer la libération non testée. Après tout, nous avons eu des délais à rencontrer.
Il y a de bonnes raisons d'avoir un développement concomitant, mais j'ai trouvé plusieurs fois ce sont les développeurs qui le demandent parce qu'il facilite leur travail. Ils n'ont pas à coordonner leurs changements car il est maintenant votre travail . Après tout, c'est pourquoi ils vous payent le gros argent.
Eh bien, pas le très gros argent, mais que vous êtes payé plus que beaucoup de gens. Peut-être pas les développeurs, mais vous faites plus que d'autres personnes de votre entreprise comme le concierge - à moins d'appartenir à un syndicat. Eh bien, vous obtenez des options d'achat d'actions.
HGGINIT.COM