Хук SVN и пакетный скрипт Windows, что не так? - PullRequest
Новая
       51

Хук SVN и пакетный скрипт Windows, что не так?

1 голос
/ 06 января 2012

Я хочу использовать svnlook, чтобы автоматически обновлять только те файлы репозитория, которые были изменены / добавлены, и так далее. У меня есть несколько приложений в моем хранилище, и все могли изменить файлы. Запуск svnlook изменил pathtomyrep дает мне файлы, это первый шаг. Как мне использовать это в пакетном файле для обновления только измененных файлов в хуке фиксации? У меня есть этот пакетный файл (post-commit.bat): 

@ECHO OFF
SET REPOS=%1
SET REV=%2
SET CHANGES=svnlook changed %REPOS% -r %REV% 
FOR /F "usebackq" %%a IN (`%CHANGES%`) DO (svn update %%a)

Бьют, ничего не происходит, код не обновляется! Я знаю, что файл работает в общем, когда я ввожу другие вещи, он выполняется. Тестируя его локально, вместо U имя файла я получаю только U . Что не так?

Спасибо:)

1 Ответ

1 голос
/ 06 января 2012

Я хочу (используйте svnlook to) обновлять только те файлы репозитория, которые были изменены / добавлены, и т. Д. Автоматически.

Вам не очень понятно, что вы хотите сделать.

  1. У вас есть какой-то ... скажем ... сайт, и когда разработчик меняетфайл в вашем хранилище Subversion, вы хотите автоматически обновить ваш сайт с этими изменениями?
  2. Вы смотрите каталог, и когда файлы изменяются в этом каталоге, вы хотите сохранить эти изменения в вашем хранилище Subversion?

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

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

Несколько способов справиться с этим:

  1. На компьютере, на котором находятся сервер и файлы.Убедитесь, что каталог, содержащий файлы, является рабочим каталогом Subversion.Если вы используете Subversion 1.7, единственный каталог .svn находится в корне рабочего каталога, что делает вещи немного чище и проще в управлении.Теперь все, что вам нужно, это запланированное задание (cronjob на языке Unix), которое запускается ... скажем ... каждые пять минут.Все, что делает эта задача - запускает обновление для этого рабочего каталога.Хук после фиксации не требуется.
  2. На вашем сервере Subversion может быть рабочий каталог, доступный для скрипта хука после фиксации.Когда происходит фиксация, ловушка post-commit обновляет этот рабочий каталог, а затем rsync в каталог на сервере, где у вас есть эти файлы. rsync будет копировать только те файлы, которые были изменены, и, следовательно, это быстрее, чем копирование всего содержимого каталога.Проблема заключается в том, что после каждого коммита пользователь, который выполнил коммит, должен ждать, пока хук post-commit обновит этот рабочий каталог и rsync, прежде чем он сможет сделать что-либо еще.
  3. Лучший способ - использоватьинструмент непрерывной интеграции, такой как Jenkins , чтобы автоматически делать все, что вам нужно, всякий раз, когда кто-то делает коммит, вместо того, чтобы полагаться на хук после фиксации.Дженкинс запишет все и сообщит, есть ли проблемы.

Я бы предпочел № 3, а затем № 1.Использование хука post-commit просто замедляет работу Subversion и расстраивает ваших разработчиков.Дженкинс легко настроить и запустить.Их поддержка превосходна, и, как и Subversion, это бесплатный инструмент с открытым исходным кодом.

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

  1. Ваш сервер настроен на использование каталога C:\foo.
  2. Обновите коммит, создайте каталог C:\bar и выполните svn exportсоздать новый и чистый каталог без каталогов .svn.
  3. После svn export finishes, you rename C: \ bar to C: \ foo`.Ваш сервер теперь использует новый каталог.

Это имеет то преимущество, что ваш сервер не использует каталог, пока файлы находятся в процессе обновления.Представьте, что есть три файла: filea.txt, fileb.txt и filec.txt.Изменения сделаны на fileb.txt и filec.txt.Эти изменения происходят вместе, и катастрофические последствия могут произойти, если они не будут развернуты в одно и то же время (вас уволят).

В какой-то момент процесса обновления fileb.txt будет в новой версии, в то время как filec.txt будет на более старой версии.Конечно, весьма маловероятно, что ваш сервер будет использовать как новую версию fileb.txt, так и более старую версию filec.txt до завершения обновления, но вы бы хотели поставить свою работу на это? .

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

...