Каков формат дельт в репозитории subversion и насколько сильно я могу его взорвать, если изменю их в хуке перед фиксацией?

Помогите мне нанести ущерб! Я устал от полдюжины запросов в Google, которые говорят мне никогда не делать этого. Давайте испортим вещи по-настоящему хорошо! Я почти уверен, что смогу получить настоящие файлы в db/transactions, так как же я могу испортить их интересным образом? Я посмотрел на SVN::Delta, но я даже не могу понять, что он должен делать (позволять кому-то делать красивые графики изменений в репозитории? отправлять закодированные сообщения в ЦРУ?).

Я действительно не хочу слышать больше причин, почему бы не сделать это. Я работаю в среде с 40 или 50 другими людьми, которые используют подрывную деятельность. И пока мы пишем код, нам нужны пароли в файлах web.config, в файлах DataSource.groovy, вы называете это. И просто отказ от коммита только потому, что мы его оставили, чертовски раздражает. Мы должны сохранить файлы с удаленными вручную паролями (и мы должны открыть эти файлы, это не значит, что они обязательно открыты), а затем, как только мы закончим фиксацию, мы должны вернуть их обратно, чтобы продолжить работу? Я полагаю, это хорошая идея, если вы просто хотите шлепать людей каждый раз, когда они что-то совершают, пока у них не выработается павловский рефлекс никогда ничего не совершать. И почему? Потому что компьютеры не должны автоматизировать задачи? Потому что программный клиент не будет знать, что хук перед фиксацией на самом деле не сохранил версию на машине разработчика?

Я довольно языковой агностик здесь. Покажите мне пример того, как сделать то, что вы никогда не должны делать... какой файл мне редактировать из предварительной фиксации? Как мне интерпретировать тарабарщину после строки DELTA # # #? Есть ли библиотеки, которые помогут с этим? Давай повеселимся!

PS Серьёзно, тег "плохие идеи" никто не создавал? ВТФ.


person John O    schedule 28.09.2011    source источник


Ответы (1)


Неисправен процесс сборки, а не Subversion. Если вы не должны фиксировать пароли, сделайте что-то вроде следующего:

1 - Web.config файлы не должны быть зафиксированы. Вместо этого зафиксируйте такие файлы, как Web.config.dev или Web.config.qa.
2. Попросите скрипт сборки переименовать соответствующий файл .config в Web.config, а затем выполните замену токена, чтобы вставить правильные пароли. Эта информация может поступать из другого файла, который также не зафиксирован, в котором указано, в какой среде вы находитесь (поэтому он знает, какой файл .config использовать) и каковы пароли.

person D'Arcy Rittich    schedule 28.09.2011
comment
Это очень мило... сказать мне, что мы не должны контролировать версии файлов. Я предполагаю, что если один из них будет утерян или поврежден во время производства (это произошло всего месяц назад), мы можем попросить их сделать резервные копии на магнитной ленте и восстановить его работоспособность через пару дней. Клиентская сторона звучит очень красиво, разработчиков всего несколько десятков... и когда через пару месяцев появятся новые компьютеры, мы сможем снова установить ее на несколько десятков систем просто для удовольствия! - person John O; 28.09.2011
comment
@Джон, я не думаю, что ты следишь за мной. Файлы, которые вы не фиксируете, автоматически генерируются вашим сценарием сборки. Единственный файл, который не создается сценарием проверки или сборки, — это файл паролей, который явно не является вашим требованием. Точно так же ваш сценарий развертывания создает для вас файл web.config. - person D'Arcy Rittich; 28.09.2011
comment
@JohnO: Нет, он говорит вам контролировать версии файлов, за исключением того, что пароли не вставлены, а затем автоматически вводить пароль. Вроде того, как вы управляете версиями файла .c, но не сгенерированного .o. - person derobert; 28.09.2011
comment
На данный момент мы используем около четырех разных IDE, не считая различных версий VS для устаревших приложений. Это также больше, чем просто написание сценариев/настройка/развертывание для тех, это означает изменение привычек более чем 50 человек, некоторые из которых будут восприимчивы, а другие нет. Здесь есть несколько человек, которые только что получили свои значки за 20 лет службы. Затем, если нам удастся сделать все это, следующее развертывание оборудования уничтожит все это, и это еще одна вещь, которую им придется вручную установить на машину, чтобы снова стать продуктивной. Что произойдет, если кто-то поработает и поместит подключение для передачи данных в другой файл? - person John O; 28.09.2011
comment
@John Похоже, у вас проблемы с разработчиком, процессом и системным (или рабочим столом) администратором. Это выходит за рамки этого вопроса, но все они решаемы. ИМО, возясь с внутренностями SVN, вы создаете еще одну проблему, а не решаете ее. - person D'Arcy Rittich; 28.09.2011
comment
Проблемы заключаются в том, что пароли для тестирования/производства случайно фиксируются в svn, а также в неизбежных обходных путях, которые люди будут использовать, если svn — это просто дубина, которой они будут бить каждый раз, когда они пытаются зафиксировать. Люди будут реже совершать коммиты (плохо) или вставлять пароли в файлы, которые мы не проверяем (хуже), или таким образом, чтобы обойти регулярные выражения, которые их находят (худшее). Я не могу промыть им всем мозги, мы не можем изменить культуру, мы не можем нанять всех новых людей, которые будут делать все правильно. Если все это можно исправить простым техническим решением, то почему бы и нет? Если подрывная деятельность делает это решение невозможным... тьфу. - person John O; 28.09.2011