Блог

Вопрос: Есть ли в SVN способ принудительно обновить файл, когда двоичный файл заблокирован? Это, по-видимому, решит проблему, с которой мы сталкиваемся ниже, путем принудительного действия блокировки для обновления файла до последней версии перед редактированием.

Предыстория: Я использую SVN (TortoiseSVN) на работе для контроля версий в качестве инженера-электрика. Многие файлы, которые у нас есть в SVN, являются двоичными файлами дизайна, которые не могут быть объединены в случае конфликта. В этих двоичных файлах дизайна у нас есть набор свойств «svn:требуется блокировка».

Проблема: У нас было несколько случаев, когда два инженера (Eng A и Eng B) проверяли двоичный файл (файл 1) в одной и той же редакции (редакция 1000). Eng A блокирует файл 1, вносит изменения, а затем фиксирует файл 1, что означает, что у Eng A теперь есть файл 1 с версией 1001.

Теперь Eng B хочет внести изменения в файл 1. Тем не менее, он все еще находится на версии 1000, хотя последние изменения в репозитории SVN относятся к версии 1001. Eng B блокирует файл 1, редактирует его, а затем фиксирует изменения и теперь находится в редакции 1002.

Проблема здесь в том, что, когда Eng B совершил коммит, его правка была основана не на изменениях Eng A в редакции 1001, а на его «устаревшей» редакции 1000. Это приводит к тому, что изменения Eng A в редакции 1001 стираются.

К сожалению, простое использование svn:needs-lock свойства не сработает в большинстве случаев. Это связано с тем, что svn попытается использовать разрешения на уровне файловой системы, чтобы сделать файл доступным только для чтения. Затем приложение двоичного файла должно сообщить пользователю, находится ли файл в состоянии только для чтения. Но большинство современных приложений просто удаляет тег «Только для чтения» и начинает перезаписывать. Вы можете прочитать больше о том, почему это не реализовано жестким способом, здесь. Информация здесь показывает «более мягкий» подход subversion к политике блокировки.

Я попытался внедрить более строгую политику блокировки, используя сценарии pre-lock и post-lock хук. Но становилось слишком много времени, чтобы поддерживать его с административной точки зрения.

Что творило чудеса без головной боли администратора, по крайней мере для небольших команд(10-15) pre-lock , post-lock так это уведомление и. Всякий раз,когда кто-то блокирует путь, людям в группе отправляется уведомление о том, что файл заблокирован, с именем пользователя, заблокировавшего путь, предупреждая пользователей не блокировать их или обновлять их. Когда блокировка снимается, группе отправляется другое уведомление, информирующее о том, что блокировка доступна для снятия.

Эта очень простая связь блокировки и разблокировки снизила скорость перезаписи работы почти до 0. Все еще были некоторые новички, которые просто начали работать, не проверяя, заблокирован файл или нет.