Como as equipes evitam a substituição do trabalho nos arquivos de origem? [fechadas]

Fechadas. Esta questão está fora de tópico . No momento, não está aceitando respostas.

Deseja melhorar esta pergunta? Atualize a pergunta para que ela esteja no tópico do Game Development Stack Exchange.

Fechado há 4 anos .

Ocorreu-me a possibilidade de que, enquanto, por exemplo, o mecanismo de jogo, esteja sendo trabalhado simultaneamente por várias pessoas, como a substituição é impedida?

Digamos que o desenvolvedor um esteja trabalhando Audio.cppe o desenvolvedor dois também esteja trabalhando Audio.cpp. Como isso geralmente é gerenciado em grandes equipes para combater a substituição? (Em outras palavras, para impedir que o desenvolvedor dois abra o arquivo até a conclusão do desenvolvedor 1 )

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

Uma das tags que você selecionou já é a resposta.

— Philipp

De fato, 3 das 4 tags são uma resposta, mas uma é a resposta.

— MSalters

Relacionados: gamedev.stackexchange.com/q/480

— moooeeeep

Respostas:

A maioria das equipes de desenvolvimento de software (não apenas no desenvolvimento de jogos) resolve esse problema usando o software de controle de versão . Exemplos são

Todas essas ferramentas têm algumas diferenças, mas o fluxo de trabalho básico é geralmente assim: existe um repositório central para o projeto com a base de código completa. Quando um desenvolvedor deseja ingressar no projeto, ele realiza um "checkout". O software de controle de versão copia a base de código para a máquina local. O software lembra a versão atual ("revisão") da base de código. Quando um desenvolvedor faz as alterações e deseja colocá-las no repositório principal, ele executa um "commit". Suas alterações são carregadas no repositório central e um novo número de revisão é criado.

Quando outro desenvolvedor agora deseja confirmar suas alterações, mas a revisão que fez o check-out não é mais a mais recente, o sistema de controle de versão não permite. O desenvolvedor precisa primeiro "puxar" as revisões que ocorreram nesse meio tempo. Isso atualiza sua cópia local para a versão mais recente no repositório central. Quando houver conflitos (as revisões intermediárias fizeram alterações em um arquivo, elas também foram alteradas), o software pode solicitar que eles resolvam o conflito editando os arquivos conflitantes manualmente (uma "mesclagem"), caso não consiga fazer isso automaticamente. Depois de fazer isso, eles podem confirmar suas alterações como uma nova revisão.

— Philipp
fonte

Observe que Git e Mercurial são sistemas de controle de versão distribuídos , que funcionam de maneira um pouco diferente: eles não exigem um único repositório central, mas teoricamente permitem que qualquer desenvolvedor obtenha atualizações diretamente de qualquer outra pessoa. Obviamente, na prática, ainda é comum ter um repositório (geralmente localizado em um host público como o GitHub) declarado o "oficial" e usado mais ou menos como o repositório central em um sistema de controle de versão não distribuído.

— Ilmari Karonen

Essa resposta também implica que a mesclagem é sempre feita manualmente. Na maioria das vezes, no entanto, o software de controle de versão pode mesclar diferenças automaticamente e requer apenas trabalho manual para alterações realmente espinhosas.

— Jhocking

Por favor, evite discussões prolongadas nos comentários, pessoal. Este não é um fórum de discussão. Use o Chat de desenvolvimento de jogos se você quiser fazer isso. Limpei vários tópicos de comentários tangenciais.

— Josh

Além disso, idealmente, cada membro da equipe seria responsável por módulos específicos quase exclusivamente, e apenas em casos raros, mais de uma pessoa modificaria o mesmo arquivo de origem dentro de um curto período de tempo, pois esse fluxo de trabalho minimiza a necessidade de mesclar alterações conflitantes. Mas isso nem sempre é o caso.

— Nicolas Miari 14/01

Os desenvolvedores não usam o mesmo arquivo.

Cada desenvolvedor tem sua própria versão do arquivo e usa um tipo especial de software para gerenciar seu trabalho. Se os dois fizerem alterações, aquele que tentar sobrescrever as alterações feitas pelo outro desenvolvedor encontrará um conflito que deve ser resolvido; caso contrário, o software de que falei começa a reclamar. Em outras palavras, o desenvolvedor que causa o conflito precisa combinar seu trabalho com o trabalho do outro desenvolvedor e somente então o arquivo pode ser "salvo".

Esta é uma explicação simples para uma parte do conceito não tão simples de controle de versão .

Eles também fazem essa coisa nova chamada comunicação e software não é escrito no vácuo. Portanto, se eles não entendem o conflito, eles conversam com a outra pessoa ou coordenam-se antes.

— Brian

Além dos pontos levantados nas outras respostas sobre controle de versão e tratamento de conflitos com mesclagens, há pelo menos duas outras maneiras pelas quais os membros da equipe podem evitar a substituição do trabalho um do outro:

Alguns sistemas de controle de versão (por exemplo, SVN) permitem o bloqueio de arquivos. Isso significa que um membro da equipe pode assumir a propriedade exclusiva de um arquivo por um período de tempo, impedindo que outros membros da equipe façam edições conflitantes (ou, na verdade, quaisquer edições) até que o arquivo seja desbloqueado posteriormente.

No entanto, isso geralmente é usado com pouca frequência, pois pode causar vários problemas. Pode reduzir a produtividade (limitando quem pode trabalhar nos arquivos a qualquer momento) e pode causar problemas se alguém esquecer de desbloquear um arquivo. Além disso, pelo menos para o SVN (não tenho certeza sobre outros VCSs), o bloqueio de um arquivo não impede que outras pessoas façam alterações em sua cópia de trabalho, apenas as impede de fazer suas alterações - isso pode resultar em esforço desperdiçado se um desenvolvedor modifica o arquivo apenas para descobrir que eles não podem confirmar suas alterações porque ele está bloqueado.
As equipes podem tentar atribuir tarefas aos desenvolvedores de forma que não tenham mais de uma pessoa trabalhando em um arquivo específico em um determinado momento. Por exemplo, cada desenvolvedor pode ser responsável por uma parte específica do projeto (por exemplo, renderização em 3D, rede, áudio, etc.) - se a base de código for bem modularizada, o desenvolvedor atribuído ao código de rede deverá ter pouca necessidade de tocar nos arquivos lidando com áudio.

Obviamente, sempre haverá alguma sobreposição que deve ser gerenciada de outra maneira.

— Mac
fonte

No lado positivo, o bloqueio é a única maneira de editar um arquivo .JPEG ou outro arquivo de texto não simples. Isso não é uma limitação teórica, apenas que as ferramentas de mesclagem geralmente são ruins.

— MSalters

@MSalters Não é que as ferramentas sejam ruins, apenas a maioria das ferramentas de mesclagem são criadas para texto, não para dados binários. E como você resolveria um conflito se duas alterações modificassem o mesmo pixel em um arquivo? Ou pior, como você levaria em consideração as alterações causadas pela compactação JPEG? É uma questão muito complexa que pode até não ter uma única solução boa; portanto, a razão pela qual a maioria das ferramentas de mesclagem não suporta é porque a necessidade disso é muito rara e a funcionalidade difícil de implementar.

— Maurycy

@MaurycyZarzycki: Alterar a mesma letra é semelhante a alterar o mesmo pixel: isso precisa de resolução manual. .JPEG provavelmente foi um mau exemplo, agora eu percebo, porque os artistas não trabalham em formatos com perdas. Mas o problema de mesclagem também existe com .PNG. No mínimo, você apreciaria se as ferramentas de mesclagem seriam capazes de mesclar XML sem quebrá-lo.

— MSalters

@MSalters Claro, com isso posso concordar muito mais.

— Maurycy

@xorsyst: Tente desta maneira: confira no SVN em dois locais. Em seguida, bloqueie um arquivo do local 1. O local 2 não saberá que está bloqueado até confirmar ou atualizar.

— Zan Lynx