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

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

1 голос
/ 28 августа 2009

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

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

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

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

Затем я нашел 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 #, чтобы я также мог указать своему серверу хранилища выполнять другие задачи, такие как запуск в сценариях базы данных и т. Д.

1 Ответ

9 голосов
/ 28 августа 2009

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

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

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

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

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

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

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

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

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

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

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

...