Есть ли быстрый способ заблокировать ствол моего хранилища SVN?

Question

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

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

Какой бы быстрый способ убедиться, что никто не отправляет в папку что-либо, пока я не закончу то, что делаю?

Спасибо

Answer 1

Если вы делаете сборку релиза, первым делом вы проверяете конкретную ревизию.

Неважно, совершит ли кто-то еще что-то в это время - это не повлияет на вашу сборку.

Answer 2

Мы столкнулись с этой проблемой при компиляции наших проектов для сборок выпуска, где свойство сервера сборки (метка проекта CruiseControl.NET) используется как часть версии сборки и установщика.

Решение легко, когда вы разветвляете (или помечаете) рабочую копию, например, для релизных сборок.

Рабочий процесс:

1. Оформление свежей рабочей копии ствола (или ветки).
2. Создайте свой выпуск, он обновляет файлы, оставляя вашу рабочую копию в измененном состоянии.
3. Если ваша сборка прошла успешно, svn скопирует рабочую копию в вашу новую ветку или тег.

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

Чтобы решить эту проблему, можно использовать svn-контроль авторизации , добавив пользователя сервера сборки в svn и иметь различные authz файлы для хранилища.

Workflow:

1. Замените authz файлом, предоставляющим права на запись для пользователя сервера сборки и права на чтение для всех остальных пользователей.
2. Выполняйте сборку как обычно.
3. Заменить authz файлом, предоставляющим обычный доступ для всех пользователей.

Обратите внимание, что авторизация svn позволяет управлять на основе пути, поэтому вы можете ограничить это только транком (или где-либо еще), чтобы уменьшить влияние на пользователей.

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

Answer 3

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

Возможности:

• Эффективно общайтесь с разработчиками.
  • Объявите, что вы собираетесь делать.
  • Разработчики должны, по крайней мере, знать, что они не должны фиксировать ветку, в которой выполняется сборка релиза.
• Делать сборки в ветке. Затем отметьте ветку, когда сборка будет завершена.
• Разработчики занимаются разработкой отдельных веток. Затем интеграционные слияния выполняются в ветке интеграции (может быть trunk).
  • Разработчики должны знать, что не следует выполнять интеграцию с веткой, в которой выполняется сборка релиза.

Answer 4

Правильный путь, по моему скромному мнению.

1. Блокировка багажника
2. создать тег
3. снять замок на багажнике
4. экспортировать тег
5. построить код
6. если сборка прошла успешно, заблокируйте отмеченную версию (в противном случае удалите ее)

Вот как я это делаю, и у меня есть скрипт для пометки части

#!/bin/bash
#
#    Copyleft
#

#
# Use with caution
#
#
#
# This script expects 2 variables in the environment to be set : USERNAME & PASSWORD
# These are needed to access our Subversion server.
#

#
# This script tags the code of each project @ HEAD
# Later version will be more sofisticated to allow tagging at a specified REVISION (it should already be the case but ... )
#
# This script must be saved un iso-8858-1 with UNIX LF
# ##############################################################################################################################################

# for debugging
set -x
set -v


# The Current verion of the tagging script is


BASEDIR=$(dirname $0)
export BASE_SVN_URL=https://my-svn-server/svn/repository/
export ROOT_DIR=../..
export VERSION="v0000.01"
export REVISION=HEAD
export TAG_NAME=TC_05

for PRJ in MODULE_1 MODULE_2 MODULE_3
do
  svn lock --username ${USERNAME} --password ${PASSWORD}  --no-auth-cache --non-interactive  --trust-server-cert   --force                     \
                                            ${BASE_SVN_URL)${PRJ}/trunk/                                                                       \
                                            -m "Locking the trunk of ${PRJ} before generating a Tagged version : ${VERSION} Tag is : ${TAG_NAME}"
done


for PRJ in MODULE_1 MODULE_2 MODULE_3
do
  svn copy --username ${USERNAME} --password ${PASSWORD}  --no-auth-cache --non-interactive  --trust-server-cert                               \
                                           ${BASE_SVN_URL)${PRJ}/trunk@${REVISION}                                                             \
                                           ${BASE_SVN_URL)${PRJ}/tags/${VERSION}/${TAG_NAME}                                                   \
                                           -m "$1"

  svn lock --username ${USERNAME} --password ${PASSWORD}  --no-auth-cache --non-interactive  --trust-server-cert                               \
                                            ${BASE_SVN_URL)${PRJ}/tags/${VERSION}/${TAG_NAME}                                                  \
                                            -m "Tagged version cannot be modified afterwards"


  svn unlock --username ${USERNAME} --password ${PASSWORD}  --no-auth-cache --non-interactive  --trust-server-cert   --force                   \
                                            ${BASE_SVN_URL)${PRJ}/trunk/                                                                       \
                                            -m "Locking before generating a Tagged version"
done

set +x
set +v

#
# TODO :
# 
# 1. Ensure that the following parameters are set correctly
#      _ username / password (though not mandatory)
#      _ Commit message, VERSION & TAG ought to be set before start
#      _ ... ?
# 2. Ensure that the directory structure exist
# 3. Ensure that the required variable are set before starting ... but anyway the script will fail :)
# 4. Check the return code of the important commands command.
# 5.

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

НО Я бы рекомендовал редко использовать svn lock.

В самом конце перед выпуском это означает, что ни одна из последних ошибок не поставит ваш выпуск под угрозу ... но хорошее общение должно позволить вам использовать почти тот же код, но с указанием номера коммита

\ T

Answer 5

В зависимости от того, сколько у вас есть доступа к серверу, отправьте объявление, в котором никому не сообщается о фиксации до некоторого времени.

Если вы не можете сделать это, тогда извлекайте / регистрируйте, используя file:// или file+ssh:// для сборок релиза и в течение этого времени завершите процесс сервера SVN. (будь то apache или svnserver), затем перезапустите его, как только сборка будет завершена.

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

Answer 6

Во-первых, вы можете попробовать выполнить эти операции на определенных ревизиях, а не на голове.

Если ревизия не является вариантом, я бы затем предложил вам пометить ревизию, которую вы хотите построить, или что-то еще, и работать с ней. Очевидно, что это не сработает для слияний, поскольку побеждает цель.

Но, чтобы понять суть вашего вопроса, самый быстрый способ, который я могу придумать, - это предотвратить поступающую информацию, это остановить сам сервер. Однако я не специалист по SVN, у меня есть администраторский ящик в течение нескольких лет.

Answer 7

Нужно ли мне снова нажать кнопку pre-commit ?

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

[ FILE The repository is now locked and you are no longer allowed to change files]
Match = .*
access = read-only
users = @ALL

[ File Except for me. I can do whatever I want]
match = .*
access = read-write
users = si

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

Что вы, вероятно, хотите сделать, это использовать ветки для релизов. Мы используем Jenkins и делаем все через номер сборки Jenkins. Разработчики скажут: «Я хочу разветвить сборку # 50, и она разветвляется, или« Давайте пометим сборку # 51, и она будет помечена.

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

[group cm]
users = si

[group Release]
users = bob, alice

[group developers]
users = robert fred cindy @Release

[file You do not have access to make changes to this repository]
match = .*
access = read-only
users = @all

[file Let all developers work on the trunk]
file = /trunk/**
access = read-write
users = @developers

[file only release group can work on the 4.5 branch]
file = /branches/4.5/**
access = read-write
users = @release

[file You cannot edit a tag. You can only create a tag]
file = /tags/*/
access = add-only
Users = all

[file CM group can do anything]
file = .*
access = read-write
users = @CM

Разрешения читаются в обратном порядке, и последнее разрешение, которое применяется к вам, это то, которое вы получаете. Разработчики могут получить доступ к транку. Выпускники могут работать в ветке 4.5, но не в других ветках. Специальный доступ add-only позволяет вам создавать теги, но не изменять теги. /tags/*/ означает, что вы можете создавать теги только непосредственно в каталоге тегов, и это должен быть каталог, скопированный из другого места.

Answer 8

Файл passwd может быть временно изменен во время выполнения работы. Недостатком является то, что это влияет на весь репозиторий, а не только на одну папку.