Как команды предотвращают перезапись работы в исходных файлах? [закрыто]

Закрыто. Этот вопрос не по теме . В настоящее время не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он соответствовал теме разработки игр для Stack Exchange.

Закрыто 4 года назад .

Мне пришла в голову возможность, что в то время, как, например, над игровым движком одновременно работают несколько человек, как предотвратить перезапись?

Допустим, разработчик один работает, Audio.cppа разработчик второй тоже работает Audio.cpp, как это обычно делается в больших командах для борьбы с перезаписью? (Другими словами, чтобы запретить разработчику два открывать файл до тех пор, пока разработчик не закончит)

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

— Этан Вебстер
источник

Один из выбранных вами тегов уже является ответом.

— Филипп

На самом деле, 3 из 4 -х тегов ответ, но один ответ.

— MSalters

Связанный: gamedev.stackexchange.com/q/480

— moooeeeep

Ответы:

Большинство команд разработчиков программного обеспечения (не только в разработке игр) решают эту проблему с помощью программного обеспечения для контроля версий . Примеры

Все эти инструменты имеют некоторые отличия, но основной рабочий процесс обычно такой: существует один центральный репозиторий для проекта с полной базой кода. Когда разработчик хочет присоединиться к проекту, он выполняет «проверку». Программное обеспечение контроля версий копирует кодовую базу на свой локальный компьютер. Программное обеспечение запоминает текущую версию («ревизию») кодовой базы. Когда разработчик вносит свои изменения и хочет поместить их в основной репозиторий, он выполняет «фиксацию». Их изменения загружаются в центральное хранилище, и создается новый номер редакции.

Когда другой разработчик теперь хочет зафиксировать свои изменения, но однажды проверенная версия уже не самая последняя, система контроля версий не позволит им. Сначала разработчик должен «вытащить» ревизии, которые произошли за это время. Это обновляет их локальную копию до самой последней версии в центральном хранилище. Когда возникают конфликты (промежуточные ревизии вносят изменения в файл, который они также изменили), программное обеспечение может попросить их разрешить конфликт, отредактировав конфликтующие файлы вручную («слияние»), если ему не удастся это сделать автоматически. После этого они могут зафиксировать свои изменения в качестве новой ревизии.

— Philipp
источник

Обратите внимание, что Git и Mercurial - это распределенные системы контроля версий, которые работают немного по-другому: им не требуется единый центральный репозиторий, но теоретически они позволяют любому разработчику получать обновления напрямую от кого-либо еще. Конечно, на практике все еще распространено, чтобы один репозиторий (часто расположенный на общедоступном хосте, таком как GitHub) объявлял «официальный» и использовал более или менее как центральный репозиторий в нераспределенной системе контроля версий.

— Илмари Каронен

Этот ответ также подразумевает, что объединение всегда выполняется вручную. Однако в большинстве случаев программное обеспечение для управления версиями может автоматически объединять различия, и для действительно сложных изменений требуется только ручная работа.

— Джокинг

Пожалуйста, избегайте расширенного обсуждения в комментариях, ребята. Это не дискуссионный форум. Используйте чат разработки игр, если вы хотите это сделать. Я почистил несколько касательных комментариев.

— Джош

Кроме того, в идеале каждый член команды должен был бы почти полностью отвечать за конкретные модули, и только в редких случаях более одного человека могли изменить один и тот же исходный файл в течение короткого периода времени, поскольку этот рабочий процесс сводит к минимуму необходимость объединения противоречивых изменений. Но это не всегда так.

— Николас Миари

Разработчики не используют один и тот же файл.

Каждый разработчик имеет свою версию файла, и они используют специальное программное обеспечение для управления своей работой. Если они оба вносят в него изменения, тот, кто пытается перезаписать изменения, сделанные другим разработчиком, столкнется с конфликтом, который должен быть разрешен, в противном случае программное обеспечение, о котором я говорил, начнет жаловаться. Другими словами, разработчик, который вызывает конфликт, должен объединить свою работу с работой другого разработчика, и только тогда файл может быть «сохранен».

Это простое объяснение части не столь простой концепции контроля версий .

Также они делают эту новую вещь, называемую коммуникацией, и программное обеспечение не написано в вакууме. Поэтому, если они не понимают конфликт, они идут поговорить с другим человеком или заранее договориться.

— Брайан

В дополнение к пунктам, поднятым в других ответах о контроле версий и обработке конфликтов со слияниями, есть по крайней мере два других способа, которыми члены команды могут избежать перезаписи работы друг друга:

Некоторые системы контроля версий (например, SVN) допускают блокировку файлов. Это означает, что один член команды может в течение некоторого времени принимать исключительное право собственности на файл, не позволяя другим членам команды вносить противоречивые изменения (или, фактически, любые изменения) до тех пор, пока файл впоследствии не будет разблокирован.

Тем не менее, это обычно используется нечасто, так как это может вызвать ряд проблем. Это может снизить производительность (путем ограничения того, кто может работать с файлами в любое конкретное время) и может вызвать проблемы, если кто-то забудет разблокировать файл. Кроме того, по крайней мере для SVN (я не уверен насчет других VCS), блокировка файла не препятствует тому, чтобы кто-то другой вносил изменения в свою рабочую копию, это только препятствует тому, чтобы они передали свои изменения - это может привести к потере усилий, если разработчик изменяет файл только для того, чтобы обнаружить, что он не может зафиксировать свои изменения, потому что он заблокирован.
Команды могут пытаться назначать задачи разработчикам таким образом, чтобы над конкретным файлом в определенный момент времени работало не более одного человека. Например, каждый разработчик может нести ответственность за определенную часть проекта (например, 3D-рендеринг, сеть, аудио и т. Д.) - если кодовая база хорошо модульна, то у разработчика, назначенного для сетевого кода, не должно быть необходимости прикасаться к файлам. занимаюсь аудио.

Конечно, всегда будет какое-то совпадение, которым нужно управлять другим способом.

— макинтош
источник

С другой стороны, блокировка - это единственный способ, которым вы можете редактировать .JPEG или другой не простой текстовый файл. Это не теоретическое ограничение, просто инструменты слияния обычно отстой.

— MSalters

@MSalters Дело не в том, что инструменты отстой, а в том, что большинство инструментов слияния созданы для текста, а не для двоичных данных. И как бы вы разрешили конфликт, если два изменения изменили один и тот же пиксель в файле? Или еще хуже, как бы вы учитывали изменения, вызванные сжатием JPEG? Это очень сложная проблема, которая может даже не иметь единственного хорошего решения, поэтому причина, по которой большинство инструментов слияния не поддерживают, заключается в том, что необходимость в этом очень редка, а функциональность трудна для реализации.

— Мориси

@MaurycyZarzycki: Изменение той же буквы похоже на изменение того же пикселя: это требует ручного разрешения. Я понимаю, что .JPEG, вероятно, был плохим примером, потому что художники не работают с форматами с потерями. Но проблема слияния также существует с .PNG. По крайней мере, вы будете признательны, если инструменты слияния смогут слить XML, не нарушая его.

— MSalters

@MSalters Конечно, с этим я могу согласиться гораздо больше.

— Мориси

@xorsyst: попробуйте это так: проверить из SVN в двух местах. Затем заблокируйте файл из местоположения 1. Местоположение 2 не будет знать, что оно заблокировано, до фиксации или обновления.

— Zan Lynx