Comment les équipes empêchent-elles le remplacement des fichiers source? [fermé]

Fermé. Cette question est hors sujet . Il n'accepte pas actuellement de réponses.

Voulez-vous améliorer cette question? Mettez à jour la question afin qu'elle soit sur le sujet pour Game Development Stack Exchange.

Fermé il y a 4 ans .

Il m'est venu à l'esprit la possibilité que pendant que, par exemple le moteur de jeu, soit utilisé simultanément par plusieurs personnes, comment l'écrasement est-il empêché?

Disons que le développeur un travaille Audio.cppet le développeur deux travaille également Audio.cpp, comment cela est-il généralement géré en grandes équipes pour lutter contre l'écrasement? (En d'autres termes, pour empêcher le développeur deux d'ouvrir le fichier jusqu'à la fin du développeur un )

project-management version-control teamwork java 2d collision-detection vector collision-resolution unity directx directx11 directx10 xna ios monogame windows-phone-8 xamarin design-patterns oop xna collision-detection collision-resolution bounding-boxes rotation collision-detection mathematics javascript algorithm separating-axis-theorem xna 2d monogame image xna directx graphics performance opengl 2d 3d c++ directx11 unity c# scale c# xna collision-detection collision-resolution leaderboards scoring glsl srgb tilemap three.js tiled unity physics xml dialog-tree xna c# .net opengl lwjgl vbo physics graphics procedural-generation simulations water opengl java textures lwjgl frame-buffer unity unity 2d collision-detection collision-resolution trigonometry java android libgdx xna c# frame-rate c++ unreal-4 procedural-generation java graphics lwjgl slick c++ software-engineering

— Ethan Webster
source

L'une des balises que vous avez sélectionnées est déjà la réponse.

— Philipp

En fait, 3 des 4 balises sont une réponse, mais l'une est la réponse.

— MSalters

EN RELATION

— moooeeeep

Réponses:

La plupart des équipes de développement logiciel (pas seulement dans le développement de jeux) résolvent ce problème en utilisant un logiciel de contrôle de version . Des exemples sont

Tous ces outils ont quelques différences, mais le flux de travail de base est généralement le suivant: Il existe un référentiel central pour le projet avec la base de code complète. Lorsqu'un développeur souhaite rejoindre le projet, il effectue une "validation". Le logiciel de contrôle de version copie la base de code sur leur machine locale. Le logiciel se souvient de la version actuelle ("révision") de la base de code. Lorsqu'un développeur a apporté ses modifications et souhaite les placer dans le référentiel principal, il effectue un "commit". Leurs modifications sont téléchargées dans le référentiel central et un nouveau numéro de révision est créé.

Lorsqu'un autre développeur souhaite maintenant valider ses modifications mais que la révision qu'il a une fois extraite n'est plus la plus récente, le système de contrôle de version ne le permet pas. Le développeur doit d'abord "tirer" les révisions qui se sont produites entre-temps. Cela met à jour leur copie locale vers la version la plus récente du référentiel central. Lorsqu'il y a des conflits (des révisions intermédiaires ont apporté des modifications à un fichier, ils ont également changé), le logiciel peut leur demander de résoudre le conflit en modifiant manuellement les fichiers en conflit (une "fusion") au cas où il ne parviendrait pas à le faire automatiquement. Après cela, ils peuvent valider leurs modifications en tant que nouvelle révision.

— Philipp
source

Notez que Git et Mercurial sont des systèmes de contrôle de version distribués , qui fonctionnent un peu différemment: ils ne nécessitent pas un seul référentiel central, mais permettent théoriquement à tout développeur de tirer des mises à jour directement de n'importe qui d'autre. Bien sûr, dans la pratique, il est encore courant qu'un référentiel (souvent situé sur un hôte public comme GitHub) le déclare "officiel" et utilisé plus ou moins comme le référentiel central dans un système de contrôle de version non distribué.

— Ilmari Karonen

Cette réponse implique également que la fusion est toujours effectuée manuellement. La plupart du temps, cependant, le logiciel de contrôle de version peut fusionner les différences automatiquement et ne nécessite un travail manuel que pour des changements vraiment épineux.

— jhocking

Veuillez éviter une discussion prolongée dans les commentaires, les amis. Ce n'est pas un forum de discussion. Utilisez le chat de développement de jeu si vous voulez le faire. J'ai nettoyé plusieurs fils de commentaires tangentiels.

— Josh

En outre, idéalement, chaque membre de l'équipe serait en charge de modules spécifiques presque exclusivement, et seulement dans de rares cas, plus d'une personne modifierait le même fichier source dans un court laps de temps, car ce flux de travail minimise la nécessité de fusionner les modifications conflictuelles. Mais ce n'est pas toujours le cas.

— Nicolas Miari

Les développeurs n'utilisent pas le même fichier.

Chaque développeur a sa propre version du fichier et utilise un type de logiciel spécial pour gérer son travail. S'ils y apportent tous les deux des modifications, celui qui essaie d'écraser les modifications apportées par l'autre développeur rencontrera un conflit qui doit être résolu, sinon le logiciel dont j'ai parlé commence à se plaindre. En d'autres termes, le développeur à l'origine du conflit doit combiner son travail avec le travail de l'autre développeur et ce n'est qu'alors que le fichier peut être "enregistré".

Il s'agit d'une explication simple pour une partie du concept autrement pas si simple de contrôle de version .

Ils font aussi cette nouvelle chose appelée communiquer et le logiciel n'est pas écrit dans le vide. Donc, s'ils ne comprennent pas le conflit, ils vont parler à l'autre personne ou se coordonner au préalable.

— Brian

En plus des points soulevés dans les autres réponses sur le contrôle de version et la gestion des conflits avec les fusions, il existe au moins deux autres façons pour les membres de l'équipe d'éviter d'écraser le travail de l'autre:

Certains systèmes de contrôle de version (par exemple SVN) permettent le verrouillage des fichiers. Cela signifie qu'un membre de l'équipe peut devenir propriétaire exclusif d'un fichier pendant un certain temps, empêchant les autres membres de l'équipe d'effectuer des modifications conflictuelles (ou, en fait, des modifications) jusqu'à ce que le fichier soit déverrouillé par la suite.

Cependant, ceci est généralement utilisé rarement, car il peut causer un certain nombre de problèmes. Il peut réduire la productivité (en limitant qui peut travailler sur des fichiers à un moment donné) et peut causer des problèmes si quelqu'un oublie de déverrouiller un fichier. De plus, au moins pour SVN (je ne suis pas sûr des autres VCS), le verrouillage d'un fichier n'empêche pas quelqu'un d'autre d'apporter des modifications à sa copie de travail, il ne fait que l'empêcher de valider ses modifications - cela peut entraîner un effort inutile si un développeur modifie le fichier uniquement pour découvrir qu'ils ne peuvent pas valider leurs modifications car il est verrouillé.
Les équipes peuvent essayer d'affecter des tâches aux développeurs de manière à ce qu'aucune personne ne travaille sur un fichier particulier à un moment donné. Par exemple, les développeurs pourraient chacun être responsables d'une partie particulière du projet (par exemple, rendu 3D, réseau, audio, etc.) - si la base de code est bien modulaire, le développeur affecté au code réseau devrait avoir peu besoin de toucher les fichiers traitant de l'audio.

Bien sûr, il y aura toujours des chevauchements qui doivent être gérés d'une autre manière.

— Mac
source

Sur le plan positif, le verrouillage est à peu près le seul moyen de modifier un fichier .JPEG ou un autre fichier en texte brut. Ce n'est pas une limitation théorique, c'est juste que les outils de fusion sont généralement nuls.

— MSalters

@MSalters Ce n'est pas que les outils sont nuls, c'est juste que la plupart des outils de fusion sont créés pour du texte, pas pour des données binaires. Et comment résoudriez-vous un conflit si deux changements modifiaient le même pixel dans un fichier? Ou pire encore, comment prendriez-vous en compte les changements causés par la compression JPEG? C'est un problème très complexe qui pourrait même ne pas avoir de bonne solution, la raison pour laquelle la plupart des outils de fusion ne prennent pas en charge est que le besoin est très rare et la fonctionnalité difficile à implémenter.

— Maurycy

@MaurycyZarzycki: Changer la même lettre est similaire à changer le même pixel: cela nécessite une résolution manuelle. .JPEG était probablement un mauvais exemple, je m'en rends compte maintenant, car les artistes ne travaillent pas sur des formats avec perte. Mais le problème de fusion existe également avec .PNG. À tout le moins, vous apprécieriez que les outils de fusion puissent fusionner XML sans le casser.

— MSalters

@MSalters Bien sûr, je peux être bien plus d'accord avec cela.

— Maurycy

@xorsyst: Essayez-le de cette façon: consultez SVN à deux endroits. Verrouillez ensuite un fichier à partir de l'emplacement 1. L'emplacement 2 ne saura pas qu'il est verrouillé jusqu'à ce qu'il soit validé ou mis à jour.

— Zan Lynx