Quelle est la méthodologie de contrôle de version la plus efficace :commander ou fusionner ?

Question

J'ai toujours utilisé Subversion ou CVS pour le contrôle de version, qui utilisent une méthodologie de « fusion ».Un de mes amis ne tarit pas d'éloges sur Perforce et à quel point il est génial avec ses listes de modifications et sa méthodologie de paiement.

Même si je suis sûr que cela dépend en grande partie de l'expérience et des préférences personnelles, je me demandais si des recherches avaient été effectuées sur la méthode de contrôle de version la plus efficace pour travailler ?

MODIFIER: Pour clarifier, je sais que Perforce et SVN autorisent le verrouillage et la fusion, mais SVN « encourage » une méthode libérale d'édition et de fusion, alors que si je comprends bien, Perforce encourage une méthode de paiement-archivage.

Answer 1

Honnêtement, je pense que cela dépend de la discipline des développeurs.

J'utilise Subversion pour mon travail personnel et je l'ai utilisé dans plusieurs emplois.Ce que j'aime dans Subversion, c'est que je n'ai pas besoin de traquer quelqu'un et de lui demander pourquoi il travaille sur quelque chose et si je peux faire du travail.Le problème survient lorsque quelqu'un décide de commencer à travailler sur quelque chose et ne l'enregistre pas pendant un certain temps ;cela peut rendre la fusion difficile car plusieurs modifications sont apportées entre leur départ et leur enregistrement.

J'utilise Perforce en ce moment et pour une raison quelconque, j'aime mieux SVN.Perforce me donne définitivement une meilleure indication qu'il va y avoir des conflits de fusion et dispose même d'outils intégrés pour m'aider à résoudre les fusions.Le problème est le même : si quelqu'un effectue des tonnes de modifications sur une longue période, la fusion sera plus difficile.

Fondamentalement, les deux modèles vous obligent à enregistrer souvent les modifications.Si vous effectuez de nombreux enregistrements, vous réduisez la probabilité que vous ayez besoin d'une fusion.Je suis coupable de garder les choses vérifiées trop longtemps et trop souvent.Personnellement, j'ai l'impression que le prix de SVN compense tout ce qui lui manque par rapport à Perforce ;Je n'ai pas encore trouvé de différence entre eux.

Answer 2

La fusion est plus efficace.Pour la simple raison que les modifications simultanées apportées au même fichier ont tendance à être courantes, et la fusion vous permet de récupérer de cela.En revanche, le paiement unique évite ce petit peu de travail supplémentaire, mais cela au prix d'énormes inefficacités dans la planification.En général, la fusion de deux modifications dans le même fichier prend peu de temps (par ex.minutes), alors qu'il faut beaucoup de temps pour apporter des modifications à un fichier (par ex.plusieurs heures ou plusieurs jours), de sorte qu'empêcher l'accès à l'édition d'un fichier constitue une énorme inefficacité.

Notez que Perforce ne force pas la méthodologie de paiement, il autorise les paiement simultanés (équivalent à une fusion).

Answer 3

Lors de notre dernière évaluation, Perforce a battu Subversion dans sa prise en charge des branchements et l'intégration des changements entre branches.Des travaux étaient en cours sur Subversion pour remédier à cette lacune, mais nous ne sommes pas revenus pour le vérifier.

Dans Perforce, lorsque vous branchez un fichier, Perforce « se souvient » d'où il vient et quelles révisions ont été « intégrées » dans les deux versions.Il comporte également quelques optimisations de stockage dans le référentiel afin qu'une copie de branche ne se matérialise pas vraiment jusqu'à ce que quelqu'un apporte une modification dans la branche, puis (si je comprends bien), il utilise des différences par rapport à la copie de base, tout comme les révisions dans un bifurquer.

Le suivi par Perforce des relations entre les succursales est un atout considérable.Si Subversion a implémenté cela maintenant, prévenez-moi.

Answer 4

Peut-être vouliez-vous dire Source Safe plutôt que Perforce ?Perforce prend en charge la fusion, et en fait avait un meilleur support de fusion que SVN jusqu'à SVN 1.5 où des fusions nommées ont été ajoutées (ainsi que des listes de modifications, que Perforce a toujours eu et cela me manque beaucoup de passer à une boutique qui utilisait SVN, mais nous avons gagné' La mise à niveau jusqu'à la version 1.5 a été testée un peu plus longtemps.)

Il convient de noter que SVN et Perforce vous permettent tous deux d'effectuer une extraction verrouillée, vous pouvez donc utiliser le modèle "non fusionné" si vous le souhaitez, mais à part peut-être la gestion des binaires avec contrôle de version, je n'en vois pas beaucoup d'utilité.

Quoi qu'il en soit, la réponse simple à votre question est "les modèles de fusion sont bien meilleurs chaque fois que plusieurs développeurs sont impliqués".

Answer 5

Si je comprends bien, Perforce rend tous les fichiers qui ne sont pas extraits en lecture seule.Ceci est similaire au comportement sous Microsoft TFS et VSS.Subversion, en revanche, ne définit pas d'attributs en lecture seule.OMI, la méthode Subversion est plus simple car vous n'avez pas à vous soucier d'un client de contrôle de source pour modifier des fichiers - vous continuez et modifiez avec un abandon imprudent, puis comparez ce qui a changé sur le disque avec le serveur lorsque vous êtes prêt. s'enregistrer.

Lorsque tous les fichiers sont en lecture seule, je me retrouve constamment à modifier un fichier, à essayer de l'enregistrer, à découvrir qu'il est en lecture seule, puis à devoir accéder au client de contrôle de code source pour le vérifier.Ce n'est pas si grave si le client de contrôle de source est intégré à votre éditeur, mais si vous stockez des éléments qui ne sont pas du code source sous contrôle de version, ce n'est souvent pas une option.

Answer 6

Si je comprends bien, Perforce rend tous les fichiers qui ne sont pas extraits en lecture seule.

Il ne s'agit que du comportement par défaut.Si nécessaire, les fichiers qui changent fréquemment peuvent être configurés pour être en lecture-écriture à la place.Voir une liste complète des modificateurs de fichiers ici.

De plus, pour mon environnement, j'utilise Eclipse avec le Plugin Perforce.Avec ce plugin, la modification d'un fichier ouvre immédiatement le fichier pour modification.

Answer 7

Je ne suis pas sûr de la recherche, mais voici un point de données pour vous :
Mon équipe a choisi PVCS (checkout) principalement pour son confort.Les doutes sur la fusion et le manque de connaissance des outils comme Subversion y ont certainement contribué.

Answer 8

Je ne suis pas sûr de comprendre la question ici - je ne connais aucun système de contrôle de source moderne (autre que Visual SourceSafe) qui ne prenne pas entièrement en charge la fusion.

Answer 9

Je préfère définitivement la méthodologie de fusion.

J'ai utilisé Visual Sourcesafe (j'espère plus jamais), CVS, Subversion et bzr.Visual sourcesafe applique la méthodologie « extraction avant édition » et peut être pénible.CVS et Subversion n'ont pas toujours été très doués pour accepter les fusions, même si j'ai entendu dire que Subversion 1.5 a amélioré cela.

Je recommanderais d’utiliser un VCS conçu dès le départ en pensant à des fusions fréquentes.bzr est celui que j'ai utilisé qui fait cela, mais les autres principaux systèmes vcs distribués (git et mercurial) le font également.

Mais finalement je ne connais aucune recherche sur ce domaine précis.En général, il existe très peu de recherches sur l'efficacité de la programmation, Logiciel populaire étant l’une des exceptions notables.

Answer 10

Je ne comprends pas vraiment la question, pour être honnête.Mais je peux garantir l'efficacité et la capacité de Perforce à gérer plusieurs personnes modifiant un fichier de manière synchronisée et à gérer la fusion des modifications.

Dans Perforce, si quelqu'un archive un fichier que vous modifiez également, alors lors de votre prochaine synchronisation à partir du serveur (c'est-à-direobtenir les derniers fichiers), vous êtes informé que certains changements doivent être résolus.Le choix du moment où le faire vous appartient.Lorsque vous « résolvez » un fichier, il effectue la fusion dans votre version locale – et les outils sont bons pour cela.

Il est important d'avoir le choix du moment où vous le faites - vous pouvez synchroniser afin de pouvoir obtenir des mises à jour qui ne sont pas directement liées à votre tâche (correction d'un bug, par exemple), et vous ne voulez pas à ce stade vous occuper de déterminer si quelqu'un d'autre la modification des mêmes fichiers sur lesquels vous travaillez vous affectera.Alors vous continuez, faites votre build et vos tests, puis vous résolvez les fichiers à votre rythme.

L'autre cas est que vous soumettez vos modifications sans avoir au préalable synchronisé avec le fichier mis à jour.Dans ce cas, Perforce empêche la soumission et signale les fichiers à résoudre.Tout développeur sensé à ce stade effectuera la fusion, puis recompilera et/ou testera avant de soumettre à nouveau la modification dans Perforce.

Ce que j'aime à ce sujet, c'est qu'il s'efforce vraiment de vous empêcher de soumettre des modifications au serveur central qui n'ont pas été explicitement traitées, ce qui minimise ainsi les risques de rupture de la version.Le processus de résolution est simple et très peu coûteux, il n’y a donc aucun problème d’efficacité.

Perforce est très explicite en vous donnant le choix et le contrôle sur la façon dont les modifications sont propagées, et le soutient avec d'excellents outils pour gérer la fusion des modifications.Personnellement, j'aime le choix et le pouvoir de faire des choix facilement.Il ne fait aucun doute que Subversion a également ses propres alternatives.

Je suppose que cela dépend probablement de ce à quoi vous êtes habitué – je ne pense pas qu’il y ait un problème d’efficacité significatif ou mesurable.