Использование Tortoise SVN в командной работе с Unreal. Я не использовал SVN более десяти лет, только Perforce и Git. Насколько я понимаю, одна из ловушек SVN заключается в том, что без тщательного общения пользователям очень легко «заблокировать» работу друг друга, поскольку по умолчанию файлы репозитория исходного кода не блокируются при извлечении для внесения изменений.
Есть ли какой-нибудь способ с помощью Tortoise или строки cmd легко заблокировать файлы сервера при проверке на наличие изменений, чтобы их нельзя было перезаписать?
Ваше понимание верно лишь отчасти. Для всего, что можно объединить (например, текстовых данных, таких как исходный код), Subversion делает все возможное, чтобы предотвратить объединение. Для файлов, которые невозможно объединить (например, двоичных файлов), вы можете заставить пользователей заблокировать их, прежде чем они начнут с ними работать.
В общем, Subversion откажется фиксировать изменения, если в репозитории есть более поздняя версия измененного файла. В этом случае Subversion требует от вас
Это упрощенная версия основного рабочего цикла Subversion , особенно пункта Разрешение любых конфликтов.
Давайте посмотрим, что это означает для данных, которые можно объединить, и для данных, которые объединить нельзя.
Хотя испортить работу ваших товарищей по команде не совсем невозможно, вам придется активно отбрасывать или перезаписывать их изменения. Хотя ошибки случаются, Subversion по своей природе не более подвержена ошибкам, чем Git или Perforce.
Блокировка всех файлов исходного кода по умолчанию наложила бы на команду ненужные ограничения.
С двоичными файлами (вы упомянули Unreal, так что, я думаю, вы будете иметь дело с файлами изображений и 3D-моделями) существует проблема: их нельзя объединить. Если возникает конфликт, вам остается принять решение использовать свое или чужое, и ничего посередине.
Чтобы внести ясность, отметим, что это все равно будет сознательное решение, которое пользователь должен принять перед внесением конфликтующего изменения. Даже если такое столкновение произойдет, оно не может остаться незамеченным.
Чтобы предотвратить этот случай, вы можете присвоить этим файлам свойство svn:needs-lock
, как описано в разделе Заставить пользователя заблокировать файл в SVN перед редактированием
В обоих случаях нет никакой гарантии, что кто-то не решит проявить чрезмерный ум или просто выбросить «неполноценную» работу товарища по команде. Существует вероятность игнорирования или неправильного использования системы, и никакой инструмент не сможет это предотвратить.
Хорошее объяснение моделей блокировки есть в уже цитированной книге Red Bean.
Если что-то случится, вы всегда можете выполнить обратное слияние своих изменений до последнего удачного состояния, как описано в разделе Отмена изменений или прямо здесь, на SO: Обратное слияние SVN?
Проблема одновременного редактирования бинарных файлов присутствует и в Git. ИМХО, централизованный характер Subversion делает его использование намного проще и безопаснее, чем Git. С другой стороны, распространение Git является основной причиной его повсеместного распространения и успеха.
У меня есть лишь избыточные знания о Perforce, поэтому следующее может быть неправильным. Насколько я помню, одновременное редактирование вообще невозможно. Открытие файла для записи заблокирует его для всех остальных членов команды. Это ведет себя как Subversion с блокировкой по умолчанию.