SVN - Как мне перехватить и изменить или добавить файлы перед фиксацией?

Прежде всего, я не уверен, что это вообще возможно, однако мне нужно знать, как это можно сделать, а если нет, то почему?

Я хочу создать приложение C #, которое запускается в соответствующее время в процессе фиксации репозитория subversion (я полагаю, до фиксации), которое затем добавит еще один файл для фиксации.

Например, я вношу изменения в Program.cs и Main.cs, но НЕ AssemblyInfo.cs. Я хочу иметь возможность принудительно изменить AssemblyInfo.cs или любой другой файл.

Я написал консольное приложение, используя SharpSVN, которое запускалось после фиксации, которое затем заменяло файл, но это вызывало увеличение номера версии. Очевидно, что это не идеально.

Затем я нашел SvnLookClient в SharpSVN, который запускается перед фиксацией, и начал что-то писать, но зашел в тупик, когда понял, что CopyFromPath означает не то, что я ожидал:

    using (SvnLookClient client = new SvnLookClient())
    {
        SvnLookOrigin o = new SvnLookOrigin(@"\\server\repository");
        SvnChangedArgs changedArgs = new SvnChangedArgs();
        Collection<SvnChangedEventArgs> changeList;
        client.GetChanged(o, changedArgs, out changeList);
    }

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


svn pre-commit sharpsvn
person djdd87    schedule 28.08.2009    source источник
comment
Почему вы хотите принудительно изменить файл, который не был изменен?   -  person bluebrother    schedule 29.08.2009
comment
Обычно вы хотите передать SvnLookOrigin, который вы можете получить через класс SvnHookArguments, а не только SvnLookOrigin(@...), потому что он смотрит на HEAD. В то время как вы, вероятно, хотите посмотреть на текущую транзакцию.   -  person Bert Huijben    schedule 26.09.2009

Ответы (1)


arrow_upward
9
arrow_downward

Вы не должны изменять транзакцию во время скрипта ловушки. Вы можете либо отклонить фиксацию с помощью сообщения (stderr будет отправлен клиенту), или сделать это отдельным коммитом в post-commit.

[edit] Я хочу пояснить, почему изменение транзакций — плохая идея (технически svn):

Клиент ничего об этом не знает.

За исключением «OK», «FAILED» и вывода stderr, во время фиксации нет обратного канала от сервера к клиенту.

Когда клиент фиксирует свои изменения и сообщается, что фиксация прошла успешно, он помечает состояние своего локального файла и папки как синхронизированное с версией репозитория [xyz]. Когда вы позже что-то измените, например, добавите файл локально, он захочет зафиксировать эти изменения, но потом... Ну, вы можете попробовать узнать, что происходит, я ожидаю что-то вроде "ошибка контрольной суммы" или "файл уже добавлен" . В зависимости от типа изменений у вас, вероятно, не будет лучшего шанса получить работающий WC, чем удаление папки и новая проверка поврежденной части.

Это была техническая часть. Теперь о стороне разработчика: во-первых, правильное автоматическое исправление изменений кажется разумным, но это не сработает из-за того простого факта, что если бы исходный код был предварительно вычисляемым, нам не пришлось бы позволять разработчикам писать его. Вы хотите, чтобы ваши разработчики поступали правильно.

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

Сообщение об ошибке от сервера svn, автоматическое письмо после неудачных сборок или модульных тестов, результаты статического анализа исходного кода и т. д. также могут служить хорошим учебным пособием.

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

И теперь я просто догадываюсь, чего вы хотите добиться: исходное дерево на стороне сервера всегда должно быть «функциональным». Тогда проблема в том, что даже с автоматическим исправлением файлов, модульным тестированием перед фиксацией, проверкой стиля и прочим, вам, наконец, все равно придется проверять, действительно ли программа работает, с помощью системного тестирования в старом стиле. Так что, по сути, вы ничего не получаете.

Технологии могут поддерживать процессы, а хорошо продуманные инструменты поддерживают их настолько хорошо, что следующие процессы действительно помогают разработчикам экономить время и упрощать рабочий процесс. Но технологии обычно не могут заменить процессы, как и человеческий интеллект (по крайней мере, пока). [/редактировать]

person gimpf    schedule 28.08.2009
comment
Я когда-то читал, что SVN в настоящее время не применяет его, но вполне может быть в будущих версиях. - person gimpf; 28.08.2009
comment
Кстати, я знаю, что вы можете сделать это через консольные программы C-API и svn (они могут обрабатывать txns как ревизии). Тем не менее, не делайте этого. Действительно. - person gimpf; 28.08.2009
comment
Не изменил файлы непосредственно в конце. На данный момент я обновляю файл Assemblyinfo.cs перед сборкой на сервере CC.Net. Я скоро перемещу его, чтобы файл Assemblyinfo не присутствовал в системе управления версиями и автоматически генерировался на стороне клиента и сервера. - person djdd87; 18.09.2009