В дни перед выпуском мы хотели бы смочь препятствовать тому, чтобы разработчики передали файлы ответвлению SubVersion, если руководитель группы не рассмотрел и утвердил изменения (в этом случае, они внесли бы временное изменение для разрешения этого).
Ранее мы использовали ClearCase, в котором это было относительно легко сделать.
Так как svn:lock управляют только работами на основе на файл, мы не уверены, можем ли мы эмулировать это поведение в SubVersion.
Чем Вы занимаетесь?
Вы можете взглянуть на svn-клиенты с графическим интерфейсом пользователя, у которых обычно более богатый интерфейс / набор функций, чем у командной строки. Например, я использую TortoiseSVN , у которого есть параметры Получить блокировку / Снять блокировку , применимые для рекурсивной блокировки всех файлов в выбранной папке. Кстати, у него также есть удобная возможность сделать тег / ветку и переключиться на нее как одно действие.
Вы можете добавить на сервер ловушку перед фиксацией, которая проверяет, содержит ли цель фиксации закрытые ветки, и, возможно, ключевое слово в сообщении журнала, чтобы обойти эту проверку.
Попутно подумав - почему бы просто не создать ответвление в точке, в которой вы хотите его "заблокировать", и проверять только этот номер ревизии в процессе сборки/релиза.
Тогда разработчики все еще смогут регистрироваться в стволе (или в любой другой ветке, над которой они работают), и если руководитель команды одобрит изменения для релиза, то они могут быть слиты в ветку. Конечно, это фактически не "блокирует" ветку релиза, но, по крайней мере, вы можете легко отслеживать/отменять изменения при необходимости, и это не мешает людям работать. Исходный текст разработчиков по-прежнему будет указывать на ветку/трубу, над которой они работали, а не на новую ветку релиза.
Создание ветвей очень дешево и просто в SVN (я верю).