2013-11-27 3 views
1

ОК, здесь моя точка зрения, у меня есть рабочая копия svn на сервере, которая должна быть обновлена. поэтому я настраиваю cronjob для обновления svn очень часто. мой скрипт просто делает обновление svn в определенный промежуток времени. Я пытаюсь использовать сценарий крюка post-commit на сервере svn, но не удалось.Концепция Subversion: обновление svn или svn info

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

У меня нет проблем при выполнении скрипта svn info, но я не думаю, что это что-то изменит.

Я ищу информацию о обновлении svn и о том, что он на самом деле делает, но не нашел что-то полезное.

изменить: @Wrikken и @Ben, прежде всего позвольте мне прояснить мое окружение. my svn environement is on lan only, поэтому мы используем протокол svn (svn: //). мой svn-сервер - это сервер ubuntu, а мой клиент - сервер debian. У меня уже есть hookscript configure и работаю на моем svn-сервере для синхронизации с третьим сервером, который является зеркалом моего svn-сервера. мой svn сервер работает с пользователем svn. мой скрипт hook и мой скрипт принадлежат одному пользователю (svn). вот мой пост фиксации сценария (команда работы svnsync отлично) #!/bin/ш

REPOS="$1" 
REV="$2" 
ME=`whoami` 

echo "post-commit $REPOS $REV user: $ME " >> /var/log/svnsync.log 

# non interactive: 
/usr/bin/svnsync sync --non-interactive svn://path/to/mirror/repository --username "user" --password "######" >> /var/log/svnsync.log 2>&1 
/path/to/script/script.sh >> /var/log/svnimpact.log 2>&1 

теперь вот мой сценарий, подключить и обновить рабочую копию на мой второй сервер (его только SVN клиент не сервер SVN)

#! /bin/sh 
/usr/bin/sshpass -p "######" /usr/bin/ssh [email protected] 'svn update /path/to/working/copy' 

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

+0

'svn info', а затем' svn update' является более тяжелым на сервере, а затем просто 'svn update', что на самом деле не так много, если нечего обновлять. Мне любопытно, какие проблемы вы столкнулись с крюком после фиксации, отлично работает здесь, чтобы запускать сборки .... – Wrikken

+0

@Wrikken Finaly мы находим наши проблемы. пользователь svn никогда не делает ssh-соединение на этом сервере раньше. поэтому с командой sshpass ему был задан пароль на вопрос, доверяли ли вы компьютеру. поэтому команда никогда не работает должным образом. мы меняем пост-фиксацию, чтобы вместо этого использовать ключ ssh, и все начинает работать, должно ли оно должно быть – bl00d666

ответ

0

Только для того, чтобы быть чистым svn info разговаривает только с сервером, если вы указываете URL-адрес или конкретную ревизию. Чтобы сделать то, что вы описываете, указав конкретную ревизию, будет контрпродуктивно, поэтому вам нужно будет указать URL-адрес. В противном случае вы будете получать информацию, которая хранится локально из последнего обновления.

Когда svn info необходимо зайти на сервер, ему необходимо получить некоторые данные о свойствах, чтобы предоставить вам вывод, который он предоставляет в выводе информации. Если вы делаете это через HTTP, он будет делать несколько запросов OPTIONS и PROPFIND.

Когда вы делаете svn update, клиент делает запрос на обновление. При этом он отправляет описание состояния рабочей копии (в вашем случае вы, вероятно, будете иметь всю рабочую копию в одной ревизии, что делает запрос довольно простым), а затем сервер отвечает на запрос, описывая как преобразовать данные, которые клиент имеет в рабочей копии в запрошенную версию (или HEAD, если версия не указана). Для этого через HTTP клиент делает несколько запросов OPTIONS и REPORT (второй запрос отчета должен поддерживать унаследованные свойства). В зависимости от клиента и сервера может потребоваться дополнительные запросы для заполнения некоторых деталей. НАПРИМЕР. более новые серверы не отправляют фактические дельта файла в ответе REPORT, а вместо этого указывают URL-адреса для их запроса (позволяет хранить эти дельты в кэше).

Теперь, на ваш вопрос, стоит ли сделать запрос svn info до svn update? Я сомневаюсь в этом.Работа, которую сервер должен выполнить для ответа на запросы PROPFIND, очень похожа на то, что ему нужно сделать, чтобы отвечать на запросы REPORT. Это заканчивается тем, что нужно дважды выполнять работу, поскольку между вашими запросами информации и обновления может быть фиксация. Я бы поставил это в той же категории, что и люди, которые запускают stat в файле, прежде чем открывать его.

Однако существуют более эффективные решения проблемы, которую вы поднимаете. Wrikken предложил использовать post-commit hook для запуска обновления. Это, безусловно, один из вариантов, хотя это означает, что сервер, на котором размещается Subversion, должен иметь способ связи с сервером, на котором вы пытаетесь запустить обновление. Большую часть времени люди делают это, разрешая доступ к ssh на сервер Subversion другим машинам. Это может быть нежелательным по соображениям безопасности.

Вместо того, чтобы кататься самостоятельно, чтобы справиться с этим сообщением или иметь дело с проблемами безопасности, позволяющими серверу Subversion получить доступ к машине, на которой вы хотите запустить обновление, вы можете использовать svnwcsub с сервером svnpubsub. Вы можете найти оба этих инструмента в каталоге tools/server-side/svnpubsub архивов Subversion 1.8.x. svnpubsub - это сервер, который распространяет уведомления о фиксации клиентам, которые подписываются на них. svnpubsub получает уведомления от крюка после фиксации с именем commit-hook.py. svnwcsub является клиентом svnpubsub, который подписывается на сервер и автоматически обновляет рабочие копии, как это было настроено, когда происходит обновление, которое повлияло бы на них.

Как только у вас есть инфраструктура svnpubsub, вы можете делать всевозможные вещи. Там есть код для подписки на обновления, а затем чирикать на фиксацию или отправить сообщение irker (IRC-боту).

+0

_ «не используйте крюк после фиксации, используйте ... post-commit hook!» _: P (Но я получаю ваша точка зрения, действительно, предоставление SSH-доступа немного для многих, достаточно других доступных механизмов. Никогда не работал с 'svnpubsub', поскольку мне никогда не нужно было больше, чем 1 вещь, слушая, обычно обыгрывая некоторые быстрые пользовательские сервисы, но я проверю это ;)) – Wrikken

+0

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

Смежные вопросы