W jaki sposób zespoły zapobiegają nadpisywaniu plików źródłowych? [Zamknięte]

Zamknięte. To pytanie jest nie na temat . Obecnie nie przyjmuje odpowiedzi.

Chcesz poprawić to pytanie? Zaktualizuj pytanie, aby było tematem dotyczącym wymiany stosów opracowywania gier.

Zamknięte 4 lata temu .

Przyszło mi do głowy, że podczas gdy, na przykład, silnik gry, pracuje jednocześnie przez wiele osób, jak można uniknąć nadpisywania?

Powiedzmy, że programista nad którym pracuje, Audio.cppa programista nad drugim również Audio.cpp, w jaki sposób jest to ogólnie zarządzane w dużych zespołach w celu zwalczania nadpisywania? (Innymi słowy, aby zatrzymać programistę dwa przed otwarciem pliku, dopóki programista jeden nie zakończy pracy)

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
źródło

Jeden z wybranych tagów jest już odpowiedzią.

— Philipp

W rzeczywistości, 3 z 4 znaczniki są odpowiedzi, ale jedno jest odpowiedź.

— MSalters

Powiązane: gamedev.stackexchange.com/q/480

— moooeeeep

Odpowiedzi:

Większość zespołów tworzących oprogramowanie (nie tylko podczas tworzenia gier) rozwiązuje ten problem za pomocą oprogramowania do kontroli wersji . Przykładami są

Wszystkie te narzędzia mają pewne różnice, ale podstawowy przepływ pracy jest zwykle taki: Istnieje jedno centralne repozytorium dla projektu z pełną bazą kodu. Gdy programista chce dołączyć do projektu, wykonuje „kasę”. Oprogramowanie do kontroli wersji kopiuje bazę kodów na komputer lokalny. Oprogramowanie zapamiętuje bieżącą wersję („wersję”) bazy kodu. Gdy programista dokonał zmian i chce je umieścić w głównym repozytorium, wykonuje „zatwierdzenie”. Ich zmiany są przesyłane do centralnego repozytorium i tworzony jest nowy numer wersji.

Gdy inny programista chce teraz zatwierdzić swoje zmiany, ale wersja, którą raz wypisali, nie jest już najnowsza, system kontroli wersji im na to nie pozwala. Deweloper musi najpierw „wyciągnąć” poprawki, które wydarzyły się w międzyczasie. To aktualizuje ich lokalną kopię do najnowszej wersji w centralnym repozytorium. Kiedy występują konflikty (w przejściowych wersjach wprowadzono zmiany do pliku, który również zmienili), oprogramowanie może poprosić ich o rozwiązanie konfliktu poprzez ręczną edycję konfliktowych plików („scalanie”), na wypadek, gdyby nie udało się tego automatycznie zrobić. Po wykonaniu tej czynności mogą zatwierdzić zmiany jako nową wersję.

— Philipp
źródło

Zauważ, że Git i Mercurial to rozproszone systemy kontroli wersji, które działają nieco inaczej: nie wymagają jednego centralnego repozytorium, ale teoretycznie pozwalają każdemu deweloperowi na pobieranie aktualizacji bezpośrednio od kogokolwiek innego. Oczywiście w praktyce wciąż zdarza się, że jedno repozytorium (często zlokalizowane na hoście publicznym, takim jak GitHub) deklaruje, że jest „oficjalne” i używane mniej więcej tak, jak centralne repozytorium w niepodzielnym systemie kontroli wersji.

— Ilmari Karonen,

Ta odpowiedź oznacza również, że scalanie odbywa się zawsze ręcznie. Przez większość czasu jednak oprogramowanie do kontroli wersji może automatycznie łączyć różnice i wymaga tylko pracy ręcznej w przypadku naprawdę drażliwych zmian.

— jhocking

Unikajcie długiej dyskusji w komentarzach, ludzie. To nie jest forum dyskusyjne. Jeśli chcesz to zrobić, skorzystaj z czatu poświęconego rozwojowi gry . Wyczyściłem kilka stycznych wątków komentarzy.

— Josh

Ponadto idealnie, gdyby każdy członek zespołu był odpowiedzialny za określone moduły prawie wyłącznie i tylko w rzadkich przypadkach więcej niż jedna osoba zmodyfikowałaby ten sam plik źródłowy w krótkim czasie, ponieważ ten przepływ pracy minimalizuje potrzebę scalania sprzecznych zmian. Ale nie zawsze tak jest.

— Nicolas Miari

Programiści nie używają tego samego pliku.

Każdy programista ma własną wersję pliku i do zarządzania swoją pracą korzysta ze specjalnego rodzaju oprogramowania. Jeśli obaj dokonają w nim zmian, ten, który próbuje zastąpić zmiany dokonane przez innego programistę, napotka konflikt, który należy rozwiązać, w przeciwnym razie oprogramowanie, o którym mówiłem, zaczyna narzekać. Innymi słowy, programista, który powoduje konflikt, musi połączyć swoją pracę z pracą innego programisty i dopiero wtedy plik można „zapisać”.

To proste wyjaśnienie części niezbyt prostej koncepcji kontroli wersji .

Robią też tę nowatorską rzecz zwaną komunikacją, a oprogramowanie nie jest pisane w próżni. Więc jeśli nie rozumieją konfliktu, najpierw rozmawiają z drugą osobą lub koordynują.

— Brian

Oprócz kwestii poruszonych w innych odpowiedziach dotyczących kontroli wersji i rozwiązywania konfliktów przy scalaniu, istnieją co najmniej dwa inne sposoby, w których członkowie zespołu mogą uniknąć wzajemnego nadpisywania swojej pracy:

Niektóre systemy kontroli wersji (np. SVN) umożliwiają blokowanie plików. Oznacza to, że jeden członek zespołu może przejąć wyłączną własność pliku przez pewien czas, uniemożliwiając innym członkom zespołu dokonywanie sprzecznych edycji (lub, w rzeczywistości, jakichkolwiek zmian), dopóki plik nie zostanie odblokowany.

Jest to jednak powszechnie stosowane rzadko, ponieważ może powodować szereg problemów. Może zmniejszyć produktywność (ograniczając, kto może pracować na plikach w danym momencie) i może powodować problemy, jeśli ktoś zapomni odblokować plik. Ponadto, przynajmniej w przypadku SVN (nie jestem pewien co do innych VCS), zablokowanie pliku nie zapobiega wprowadzeniu zmian w kopii roboczej przez kogoś innego, tylko zapobiega ich zatwierdzeniu - może to prowadzić do zmarnowanego wysiłku, jeśli programista modyfikuje plik tylko w celu wykrycia, że nie może zatwierdzić swoich zmian, ponieważ jest on zablokowany.
Zespoły mogą próbować przypisywać zadania programistom w taki sposób, aby nie mieli więcej niż jednej osoby pracującej nad danym plikiem w danym momencie. Na przykład, programiści mogą być odpowiedzialni za określoną część projektu (np. Renderowanie 3D, sieć, audio itp.) - jeśli podstawa kodu jest dobrze zmodularyzowana, to programista przypisany do kodu sieci nie powinien dotykać plików radzenie sobie z dźwiękiem.

Oczywiście zawsze zachodzi pewne nakładanie się, którym należy zarządzać w inny sposób.

— Prochowiec
źródło

Plusem jest to, że blokowanie jest jedynym sposobem edycji pliku .JPEG lub innego pliku innego niż zwykły tekst. To nie jest teoretyczne ograniczenie, po prostu narzędzia do scalania zwykle są do kitu.

— MSalters

@MSalters To nie jest tak, że narzędzia są do bani, po prostu większość narzędzi do scalania jest tworzona dla tekstu, a nie dla danych binarnych. Jak rozwiązałbyś konflikt, gdyby dwie zmiany zmodyfikowały ten sam piksel w pliku? A co gorsza, jak uwzględniłbyś zmiany spowodowane kompresją JPEG? Jest to bardzo złożony problem, który może nie mieć nawet jednego dobrego rozwiązania, dlatego większość narzędzi do scalania nie obsługuje, ponieważ potrzeba jest bardzo rzadka, a funkcjonalność trudna do wdrożenia.

— Maurycy

@MaurycyZarzycki: Zmiana tej samej litery jest podobna do zmiany tego samego piksela: wymaga ręcznego rozwiązania. Rozumiem, że .JPEG był prawdopodobnie złym przykładem, ponieważ artyści nie pracują nad stratnymi formatami. Ale problem z scalaniem istnieje również w .PNG. Przynajmniej byłbyś wdzięczny, gdyby narzędzia do scalania byłyby w stanie scalić XML bez jego łamania.

— MSalters

@MSalters Jasne, dzięki czemu mogę zgodzić się znacznie więcej.

— Maurycy

@xorsyst: Wypróbuj w ten sposób: sprawdź z SVN w dwóch lokalizacjach. Następnie zablokuj plik z lokalizacji 1. Lokalizacja 2 nie będzie wiedziała, że jest zablokowana do czasu zatwierdzenia lub aktualizacji.

— Zan Lynx,