Вопрос по svn – SVN автоматическое форматирование кода при регистрации?

11

Это возможно? Если да, то как мне это сделать?

Код находится на C #, и мы используем TortoiseSVN.

Я просто хочу автоматически форматировать код при каждой проверке.

большое спасибо

Ваш Ответ

6   ответов
3

Это возможно, но тоже очень и очень плохая идея.

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

Тем не менее, если вы хотите сделать это, посмотрите на использование pre-commit hooks.

Работает ли сервер SVN в системе Windows или Linux? А какой код-форматер вы хотите использовать?

В этом случае я мало чем могу помочь ... Я мало что знаю о Subversion в Windows ... Но, похоже, @Yoopergeek вас там охватил. В любом случае, одна вещь, которую вы, возможно, захотите рассмотреть, состоит в том, чтобы вместо добавления ловушки написать скрипт, чтобы разработчики могли легко форматировать свой код. Затем, если есть проверенный код, вы можете вежливо попросить их использовать этот инструмент.
Да, для меня это тоже не очень хорошая идея. Некоторая дисциплина со стороны кодировщиков НАМНОГО безопаснее, чем неработающий код.
Я смотрю на NArrange (narrange.net) SuperSuperDev1234
6

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

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

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

5

Я очень рекомендую это.

Используйте сценарий предварительной фиксации или, что еще лучше, найдите способ сделать это автоматически в вашей среде IDE (предварительная фиксация передаст измененный файл клиенту). Затмение может автоматически форматировать при сохранении.

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

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

Я работал с cvs и java и использовал jalopy для автоматического форматирования. Мы использовали систему ветвления, поэтому она была обязательной и работала очень хорошо.

6

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

27

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

Если вы измените данные, которые будут зафиксированы, клиент об этом не узнает. Поэтому после такого коммита, где ваш скрипт «исправляет» форматирование файла, содержимое файла в хранилище отличается от файлов в вашей рабочей копии. Но ваша рабочая копия все еще думает, что она обновлена с репозиторием (в конце концов, его модификации только что были зафиксированы).

Так что при следующем обновлении вы попадете в ад - испорченная рабочая копия, недовольные пользователи, ...

И, конечно же, вы можете нарушить сборку - иногда это имеет место при автоматическом форматировании.

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

И поскольку вы используете TortoiseSVN, вы можете попробовать выполнить форматирование вхук предварительной фиксации на стороне клиента.

Нет, обновление не исправит это. Обновление получит различия между ревизией, в которой находятся файлы рабочей копии, и хранилищем. Но так как они одинаковы, обновление ничего не даст. Вот почему я сказал, что рабочая копия сломана.
Если вы внесете изменения в содержимое сценария предварительной фиксации, эти изменения будут отправлены обратно клиенту. Например, замена ключевого слова означает, что это произойдет.
Это лучшая причина дляnot Для этого: repo & lt; - & gt; несоответствие рабочей копии. Очень хороший момент.
Нет, такие измененияnot отправлено обратно клиенту. Замена ключевого слова производится на стороне клиентаafter фиксация, но для этого клиент должен знать только то, что он отправил в репозиторий, а не то, что репозиторий сделал с ним. Конечно, репозиторий отправляет полученную ревизию обратно клиенту, и это все, что необходимо для расширения ключевого слова. Но хранилище не отправляет обратно изменения, выполненные скриптом ловушки. Я знаю, о чем я говорю, поверь мне :)
Проблема с конфликтной / устаревшей рабочей копией ничем не отличается от ситуации, когда кто-либо другой фиксирует новую версию файла в хранилище. Это будет решено путем получения последней версии с сервера, и если пользователь забудет, клиент svn обнаружит это при попытке снова зафиксировать файл.
17

Вы касаетесь святой войны. Суета с форматированием людей требует вил и факелов.

Моя рекомендация:Don't.

Не говоря уже о том, что если вы говорите на C #, а ваши разработчики используют Visual Studio, в VS имеется множество инструментов для автоматического форматирования. Просто введя эту закрывающую фигурную скобку и VS может / автоматически отформатирует ваш код.

Лучшим решением может быть то, чтобы все ваши разработчики использовали одинаковые настройки автоформатирования.

Tools -> Options, Text Editor -> C# ->Formatting

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

Если вы одержимы этим, то, как и другие говорили, ловушка предварительной фиксации - это путь. Если вы работаете с SVN-сервером в Windows, могу я порекомендоватьКапитанский крюк для написания скриптов хуков? Подключаемые плагины, которые вы можете написать на любом языке .NET.

Полностью согласен & # x2013; проверьте параметры форматирования кода в хранилище, тогда каждый может поделиться ими.
Для CaptainHook, возьмите файл патча, чтобы исправить пару ошибок
Я не уверен, о каком патче вы говорите ... Примечание: недавно я перенес наш SVN-сервер на новую виртуальную машину и повторно посетил все наши старые скрипты CaptainHook & quot; сценарии & quot ;. Поскольку я изначально работал с CaptainHook, я с тех пор работал с SharpSVN над другими проектами и действительно хотел бы, чтобы у меня было время переоборудовать CaptainHook для использования SharpSVN, так как кажется глупым иметь CaptainHook внутри, используя инструменты командной строки SVN для этого. Работа.
Ого. Пока вы просто не заявили об этом, мне не приходило в голову включить экспортированные параметры форматирования VS в проект в систему управления версиями. Это хорошая идея.

Похожие вопросы