Branches de développement Perforce - Branchement simplifié vs branchement privé

Question

Je cherche des commentaires sur les avantages et les inconvénients des méthodes disponibles pour créer des branches de développement individuelles dans un dépôt Perforce. Si je comprends bien, il y a deux façons de gérer cela. Le premier consiste à créer une branche privée, qui est une copie complète de la branche sur laquelle vous travaillez. La branche serait complètement autonome et isolerait complètement vos changements de la branche cible.

L'autre méthode que j'ai entendu recommandé est la ramification clairsemée. Il est décrit dans Practical Perforce (Chapitre 9, p.242). Cela crée une branche, mais uniquement avec les fichiers que vous devrez modifier. Vous chevauchez ensuite la vue du client de branche cible avec cette vue de client de branche de développement clairsemée.

Les deux méthodes nécessiteraient que le programmeur effectue un travail d'intégration afin d'obtenir leurs modifications dans la branche cible. La méthode Private Branch semble nécessiter beaucoup plus de mémoire supplémentaire pour créer une copie de la branche entière. Cependant, la documentation de Perforce indique qu'elle effectue une "copie paresseuse" dans cette situation. L'intégration permet également à Perforce d'effectuer une "copie paresseuse" des fichiers. Lorsque vous branchez fichiers, le serveur ne détient pas réellement deux copies des fichiers - il contient simplement le fichier source et un pointeur dans la base de données enregistre le fait que la branche dans le fichier cible s'est produite. Les copies paresseuses font de l'embranchement une opération à faible coût; le serveur n'a pas à garder trace des copies de fichiers en double. Cela donne l'impression que la méthode de la branche Sparse ajoute simplement la possibilité d'erreur humaine au processus, par exemple, le développeur peut commencer à travailler sur un fichier qu'il n'a pas ajouté à la branche Sparse et puis mettez accidentellement à jour une modification de la branche cible qui casse la construction. Mais, la fonctionnalité de branchement Sparse existe pour une raison. Tout retour sur pourquoi il existe et pourquoi je devrais l'utiliser sur une branche privée complète (ou vice versa) serait grandement apprécié.

Answer 1

Comme vous l'avez noté de l'espace de documentation n'est pas vraiment un problème. La vitesse est cependant. La synchronisation de tout l'arbre de développement peut prendre beaucoup de temps. L'intégration va aussi prendre du temps. Si vous avez seulement besoin d'une branche de l'arbre, alors ces deux opérations sont beaucoup plus rapides.

Une erreur humaine, comme vous l'avez déjà dit, peut se produire, mais si vous créez une spécification de branche, elle peut aider à atténuer certaines erreurs potentielles.

Answer 2

La vitesse de synchronisation et l'espace disque client sont des problèmes liés à la création de branches complètes (aide à la copie paresseuse sur le serveur, mais pas sur le réseau ou le client). Cependant, j'ai trouvé qu'il est plus facile à installer et à comprendre que d'essayer de créer une branche clairsemée, de sorte que les branches complètes sont ce que nous finissons par utiliser.

Answer 3

Une bonne situation dans laquelle un branchement clairsemé est approprié est lorsque vous avez un produit complexe potentiellement composé de beaucoup de modules. Supposons que la construction prenne beaucoup de temps pour l'ensemble du système et que la synchronisation prenne un certain temps - beaucoup de fichiers de données. Mais votre développement a seulement besoin de modifier un petit sous-ensemble de la base de la source entière - peut-être un module ou deux, avec éventuellement un code de liaison "plus haut".

Dans ce cas, faire une branche clairsemée peut avoir beaucoup de sens. Cela signifie que vous avez déjà synchronisé la majeure partie des choses, et probablement déjà construit aussi. Mais vous devez faire attention à ce que tous les fichiers que vous modifiez soient branchés en premier - sinon vous risquez de casser la ligne principale. Certes, cela nécessite plus de soin de la part du programmeur.Un autre cas où le branchement clairsemé peut être la seule façon pratique de faire du développement ramifié est s'il est difficile d'avoir plus d'une version de votre application sur une machine de développement. Dans ce cas, il serait difficile d'avoir à la fois une construction de ligne principale et un bâtiment de construction de développement et de courir côte à côte. Évidemment pas idéal, mais certains produits sont comme ça soit par nécessité ou par histoire.