svn hook для генерации файла из зафиксированных файлов - PullRequest
Новая
       16

svn hook для генерации файла из зафиксированных файлов

2 голосов
/ 11 декабря 2011

У меня есть SVN-репозиторий с 

trunk/file1.txt
trunk/file2.txt
trunk/fileR.txt

На сервере у меня есть проверка рабочей копии ствола (/var/www/trunk), принадлежащая пользователю www-data.

fileR.txt доступно только для чтения всем, кроме пользователя www-data (доступ ограничен authz или svnlook author). fileR.txt должно быть получено путем объединения file1.txt и file2.txt: cat file1.txt file2.txt > fileR.txt

Я хочу, чтобы каждый раз, когда происходит фиксация на trunk/file1.txt или trunk/file2.txt, должен запускаться сценарий, который обновляет рабочую копию на сервере, объединяет файлы и передает новый fileR.txt в хранилище.

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

Пример: Итак, заходит commit1 с изменениями file1.txt, запускается ловушка перед фиксацией (если есть), транзакция фиксируется в базе данных, а затем запускается ловушка после фиксации. Хук post-commit фактически создает commit2, который необходимо завершить, прежде чем хук post-commit из commit1 действительно завершит работу.

Может ли SVN сделать это? Если нет, какие другие инструменты / рабочие процессы вы предлагаете?

Спасибо

1 Ответ

1 голос
/ 11 декабря 2011

Допустим, вы делаете хук после фиксации, чтобы делать то, что вы хотите ...

  1. Я фиксирую изменение в file1.txt.
  2. Хук Post-commit забирает изменения и создает новый файл fileR.txt
  3. Изменение после фиксации фиксирует это изменение, которое вызывает срабатывание ловушки перед фиксацией.
  4. И вы вернулись к шагу № 1

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

И, пока ваш хук после фиксации делает все это, вы, пользователи, должны ждать завершения хука после фиксации.

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

Я надеюсь, что убедил вас, что это не очень хорошая идея. Это возможно возможно, но это определенно не рекомендуется. Фактически, если бы я видел, как инженер-строитель сделал что-то подобное, я бы их уволил.

Предлагаю вам взглянуть на Дженкинс . Jenkins - это сервер непрерывной сборки. Что вы можете сделать, это попросить Дженкинса создать файл fileR.txt для вас каждый раз, когда будет сделан коммит. Этот файл можно легко загрузить с сервера Jenkins и сделать его общедоступным. Вы также можете взять свой fileR.txt и создать PDF для людей, пока вы там.

Итак, ваш объединенный файл все еще доступен и может быть загружен другими процессами, но это не заставит ваш хук после фиксации запустить еще один раунд хуков. И, fileR.txt только для чтения всеми, кто имеет доступ к этой конкретной работе Jenkins.

...