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

Asked
Viewd11151

11

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

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

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

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

11151

6 ответов

15

Вы касаетесь священной войны. Возиться с форматированием людей - значит просить вилы и факелы.

Моя рекомендация: Не .

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

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

Инструменты -> Параметры, Текстовый редактор -> C # -> Форматирование

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

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

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

    Yoopergeek19 июня 2009, 13:55
  • Полностью согласен - проверьте параметры форматирования кода в репозитории, и каждый сможет поделиться ими.

    David Wolever19 июня 2009, 13:47
3

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

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

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

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

  • Да, мне тоже не кажется хорошей идеей. Некоторая дисциплина со стороны кодеров НАМНОГО безопаснее, чем сломанный код.

    crashmstr19 июня 2009, 13:34
  • В этом случае я ничем не могу помочь ... Я мало знаю о Subversion для Windows ... Но похоже, что @Yoopergeek вас там накрыл. В любом случае, вы, возможно, захотите рассмотреть одну вещь: вместо добавления ловушки напишите сценарий, чтобы разработчики могли легко форматировать свой код. Затем, если обнаружен уродливый код, вы можете вежливо попросить их использовать этот инструмент.

    David Wolever19 июня 2009, 13:46
7

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

5

Очень рекомендую.

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

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

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

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

27

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

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

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

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

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

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

  • Это лучшая причина, чтобы не этого делать: репо несогласованность рабочей копии.

    Очень хорошее замечание.

    Yoopergeek19 июня 2009, 13:46
  • Если вы внесете изменения в содержимое сценария предварительной фиксации, эти изменения будут отправлены обратно клиенту. Например, замена ключевого слова указывает на то, что это произойдет.

    Michael Wiles19 июня 2009, 14:38
  • Нет, обновление не исправит этого. Обновление получит различия между ревизией, в которой находятся файлы рабочей копии, и репозиторием. Но поскольку они такие же, обновление ничего не даст. Вот почему я сказал, что рабочая копия ломается.

    Stefan19 июня 2009, 14:24
  • Я думаю, что проблема, как заявляет Стефан, заключается в том, что, совершая фиксацию, вы тем самым вынуждаете коммитера выполнять обновление сразу после фиксации, потому что ловушка предварительной фиксации изменит их код.

    Yoopergeek19 июня 2009, 13:54
  • Нет, такие изменения не отправляются обратно клиенту. Замена ключевого слова выполняется на стороне клиента после фиксации, но для этого клиенту нужно знать только то, что он отправил в репозиторий, а не то, что репозиторий с ним сделал. Конечно, репозиторий отправляет полученную ревизию обратно клиенту, и это все, что нужно для расширения ключевых слов. Но репозиторий не отправляет обратно изменения, которые были выполнены сценарием ловушки. Я знаю, о чем говорю, поверьте мне :)

    Stefan19 июня 2009, 15:00
  • Проблема с конфликтом / устаревшей рабочей копией ничем не отличается от ситуации, когда кто-либо еще зафиксировал новую версию файла в репозитории. Это будет решено путем получения последней версии с сервера, и, если пользователь забудет, клиент svn обнаружит это при повторной попытке зафиксировать файл.

    Anders Sandvig19 июня 2009, 13:50
  • @Michael Wiles: у вас, вероятно, есть какая-то собственная сборка SVN. Единственный способ получить изменения хуков перед фиксацией для клиента, который их зафиксировал, - это «фиксация-> обновление до более низкой версии-> обновление обратно в HEAD». »; в противном случае клиент думает: «У меня уже есть версия HEAD, обновлять не нужно», и поэтому не получит изменений, внесенных вашими хуками.

    OTOH, если каждая (настоящая) фиксация вызвала изменение форматирования и другую автоматическую фиксацию, это могло бы сработать (но привело бы к непрактичному рабочему процессу: «фиксация-> дождитесь автоматического переформатирования и повторно зафиксируйте-> обновите до переформатированной версии. ”); будьте осторожны, петли.

    Piskvor left the building21 февраля 2010, 15:16
6

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

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

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