Лучший способ убедиться, что установлена ​​правильная версия файла? - PullRequest
1 голос
/ 03 ноября 2008

Компания, в которой я работаю, пишет множество небольших скриптов Perl и Bash, чтобы превратить данные в нечто полезное для нашего программного обеспечения. Эти скрипты, как и любой код, могут меняться. Я предоставил им CVS из-за версий файлов, а не из-за версий репозитория. Во всяком случае, я обдумываю инструмент развертывания, чтобы получить сценарии от разработки до производства. Производственный сервер будет иметь свою собственную простую систему управления версиями, в которой если сумма md5 одного из сценариев не совпадает с суммой в базе данных, он не будет запускать сценарий и посылать сообщения соответствующим сторонам.

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

Что лучше для этого сделать? Это так же просто, как сделать 'cvs diff'?

Ответы [ 2 ]

1 голос
/ 03 ноября 2008

если вы собираетесь написать какой-то сценарий распространения, он должен быть относительно простым

1) Скрипт должен быть зафиксирован в вашем репозитории cvs

2) Я советую вызывать скрипт из вашего make-файла (или любой используемой вами системы сборки) как то так

make dist

и правило dist вызовет ваш скрипт.
3) скрипт выполнит

 cvs up -An 

и проанализируйте вывод, чтобы найти состояние M или C или A или R например, перенаправив вывод в grep.

grep -c ^[MCAR] 

если считать> 0, у вас проблема.

4) если один из вышеперечисленных завершится неудачно, скрипт сборки

5) если вы не создаете tar или любую другую форму дистрибутива, которую вы используете

Чтобы развернуть более старую версию, вы можете сделать параметр -A по умолчанию равным -A и переопределить, например, переменной оболочки, например, -r tag-3.14.4.

0 голосов
/ 04 ноября 2008

Я работал над внутренним инструментом, который делал развертывания. Он был разработан для предприятия (и соответствовал нормам SOX), поэтому для развертывания кода использовались разрешения.

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

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

...