In che modo i team impediscono il lavoro di sovrascrittura nei file di origine? [chiuso]

Chiuso. Questa domanda è fuori tema . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che sia in argomento per lo scambio di stack di sviluppo giochi.

Chiuso 4 anni fa .

Mi è venuta in mente la possibilità che mentre, per esempio, il motore di gioco, viene lavorato contemporaneamente da più persone, come viene impedita la sovrascrittura?

Supponiamo che lo sviluppatore uno stia lavorando Audio.cppe anche lo sviluppatore due stia lavorando Audio.cpp, come viene generalmente gestito in grandi gruppi per combattere la sovrascrittura? (In altre parole, per impedire allo sviluppatore due di aprire il file fino al termine dello sviluppatore )

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
fonte

Uno dei tag che hai selezionato è già la risposta.

— Philipp,

In effetti, 3 dei 4 tag sono una risposta, ma uno è la risposta.

— Salterio del

Correlato: gamedev.stackexchange.com/q/480

— moooeeeep

Risposte:

La maggior parte dei team di sviluppo software (non solo nello sviluppo di giochi) risolve questo problema utilizzando il software di controllo versione . Ne sono esempi

Tutti questi strumenti presentano alcune differenze, ma il flusso di lavoro di base è in genere il seguente: esiste un repository centrale per il progetto con la base di codice completa. Quando uno sviluppatore vuole unirsi al progetto, esegue un "checkout". Il software di controllo della versione copia la base di codice sul proprio computer locale. Il software ricorda la versione corrente ("revisione") della base di codice. Quando uno sviluppatore ha apportato le modifiche e desidera inserirle nel repository principale, esegue un "commit". Le loro modifiche vengono caricate nel repository centrale e viene creato un nuovo numero di revisione.

Quando un altro sviluppatore ora desidera eseguire il commit delle modifiche, ma la revisione che hanno effettuato il checkout non è più la più recente, il sistema di controllo della versione non le consente. Lo sviluppatore deve prima "tirare" le revisioni avvenute nel frattempo. Questo aggiorna la loro copia locale alla versione più recente nel repository centrale. In caso di conflitti (le revisioni intermedie hanno apportato modifiche a un file che hanno anche modificato), il software potrebbe chiedere loro di risolvere il conflitto modificando manualmente i file in conflitto (una "fusione") nel caso in cui non riesca a farlo automaticamente. Dopo averlo fatto, possono eseguire il commit delle modifiche come una nuova revisione.

— Philipp
fonte

Nota che Git e Mercurial sono sistemi di controllo della versione distribuiti , che funzionano in modo leggermente diverso: non richiedono un unico repository centrale, ma teoricamente consentono a qualsiasi sviluppatore di estrarre gli aggiornamenti direttamente da chiunque altro. Naturalmente, in pratica, è ancora comune avere un repository (spesso situato su un host pubblico come GitHub) dichiarato "ufficiale" e utilizzato più o meno come il repository centrale in un sistema di controllo della versione non distribuito.

— Ilmari Karonen,

Questa risposta implica anche che l'unione viene sempre eseguita manualmente. Il più delle volte, tuttavia, il software di controllo della versione è in grado di unire automaticamente le differenze e richiede solo un lavoro manuale per modifiche davvero spinose.

— scherzando l'

Si prega di evitare discussioni approfondite nei commenti, gente. Questo non è un forum di discussione. Usa la chat di sviluppo del gioco se vuoi farlo. Ho ripulito diversi thread di commenti tangenziali.

— Josh,

Inoltre, idealmente ogni membro del team dovrebbe occuparsi quasi esclusivamente di moduli specifici e solo in rari casi più di una persona modificherà lo stesso file di origine in un breve periodo di tempo, poiché questo flusso di lavoro riduce al minimo la necessità di unire le modifiche in conflitto. Ma questo non è sempre il caso.

— Nicolas Miari,

Gli sviluppatori non usano lo stesso file.

Ogni sviluppatore ha la propria versione del file e utilizza un tipo speciale di software per gestire il proprio lavoro. Se entrambi apportano modifiche, quello che tenta di sovrascrivere le modifiche apportate dall'altro sviluppatore incontrerà un conflitto che deve essere risolto, altrimenti il software di cui ho parlato inizia a lamentarsi. In altre parole, lo sviluppatore che causa il conflitto deve combinare il proprio lavoro con quello dell'altro sviluppatore e solo allora il file può essere "salvato".

Questa è una semplice spiegazione per una parte del concetto altrimenti non così semplice di controllo della versione .

Inoltre fanno questo romanzo chiamato comunicazione e il software non è scritto nel vuoto. Quindi se non capiscono il conflitto, vanno a parlare con l'altra persona o si coordinano in anticipo.

— Brian,

Oltre ai punti sollevati nelle altre risposte sul controllo della versione e sulla gestione dei conflitti con le fusioni, ci sono almeno altri due modi in cui i membri del team possono evitare di sovrascrivere il lavoro reciproco:

Alcuni sistemi di controllo della versione (ad es. SVN) consentono il blocco dei file. Ciò significa che un membro del team può assumere la proprietà esclusiva di un file per un certo periodo di tempo, impedendo ad altri membri del team di apportare modifiche in conflitto (o, in realtà, qualsiasi modifica) fino a quando il file non viene successivamente sbloccato.

Tuttavia, questo è generalmente usato raramente, in quanto può causare una serie di problemi. Può ridurre la produttività (limitando chi può lavorare sui file in un determinato momento) e può causare problemi se qualcuno dimentica di sbloccare un file. Inoltre, almeno per SVN (non sono sicuro degli altri VCS), il blocco di un file non impedisce a qualcun altro di apportare modifiche alla sua copia di lavoro, ma impedisce loro di confermare le modifiche; ciò può comportare uno spreco di risorse se uno sviluppatore modifica il file solo per scoprire che non possono eseguire il commit delle modifiche perché è bloccato.
I team possono provare ad assegnare compiti agli sviluppatori in modo tale che non abbiano più di una persona che lavora su un determinato file in un determinato momento. Ad esempio, ciascuno sviluppatore potrebbe essere responsabile di una parte particolare del progetto (ad es. Rendering 3D, rete, audio, ecc.) - se la base di codice è ben modularizzata, lo sviluppatore assegnato al codice di rete dovrebbe avere poco bisogno di toccare i file occuparsi di audio.

Naturalmente, ci saranno sempre delle sovrapposizioni che devono essere gestite in altro modo.

— Mac
fonte

Tra i lati positivi, il blocco è l'unico modo in cui è possibile modificare un .JPEG o un altro file di testo non semplice. Questa non è una limitazione teorica, è solo che gli strumenti di unione di solito fanno schifo.

— Salterio del

@MSalters Non è che gli strumenti fanno schifo, è solo che la maggior parte degli strumenti di unione sono creati per il testo, non per i dati binari. E come risolverebbe un conflitto se due modifiche modificassero lo stesso pixel in un file? O peggio ancora, come valuteresti i cambiamenti causati dalla compressione JPEG? È un problema molto complesso che potrebbe non avere nemmeno un'unica soluzione valida, quindi il motivo per cui la maggior parte degli strumenti di unione non supporta è perché la necessità è molto rara e la funzionalità difficile da implementare.

— Maurycy,

@MaurycyZarzycki: la modifica della stessa lettera è simile alla modifica dello stesso pixel: è necessario risolverlo manualmente. .JPEG probabilmente è stato un cattivo esempio, ora capisco, perché gli artisti non lavorano su formati con perdita di dati. Ma il problema di unione esiste anche con .PNG. Come minimo, apprezzeresti se gli strumenti di unione sarebbero in grado di unire XML senza romperlo.

— Salterio del

@MSalters Certo, con ciò posso essere molto più d'accordo.

— Maurycy,

@xorsyst: provalo in questo modo: controlla da SVN in due posizioni. Quindi bloccare un file dalla posizione 1. La posizione 2 non saprà che è bloccata fino al commit o all'aggiornamento.

— Zan Lynx,