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

Question

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

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

Answer 1

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

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

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

За исключением "OK", "СБОЙ" и выходных данных stderr, во время фиксации нет обратного канала от сервера к клиенту.

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

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

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

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

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

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

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