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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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