Может ли SVN делать что-то вроде атрибутов git filter?

Question

Я не очень знаком с git, но похоже, что он может использовать атрибуты фильтра, например, для аккуратных файлов XML перед фиксацией. Руководство SVN специально (и настоятельно) не советует использовать для этого хуки перед фиксацией. Есть ли другой способ?

Answer 1

Ответ на этот вопрос: нет.Я считаю, что отклонение коммита - это единственный безопасный вариант с SVN.

Answer 2

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

Однако Subversion имеет централизованное хранилище, что означает, что манипулирование файлами во время фиксации сложнее и обычно не рекомендуется.

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

Даже с такими системами управления версиями, как Git и ClearCase, где можно взломать файлы во время коммита, это все равноне хорошая идея.Прежде всего, это может замедлить процесс фиксации при запуске скрипта ловушки, что может расстроить пользователя.Во-вторых, что произойдет, если процесс взлома фактически сломает файл?Предполагается, что разработчики тестируют и проверяют свои изменения перед их фиксацией.«Сломать сборку» - это преступление даже хуже, чем взять последнюю чашку кофе в комнате отдыха и не приготовить еще одну кастрюлю.Тем не менее, вот разработчик, который сделал все, что предполагалось, и это был глупый хук-скрипт, который сделал это!

Это то, что должно быть сделано в процессе автоматической сборки (вы используете инкрементную сборку).система вроде CruiseControl или Hudson не так ли?).Это можно сделать как часть тестирования, и сборка может быть помечена как «нестабильная», если файл не отформатирован правильно.На самом деле, у Hudson есть хуки, которые могут сделать это как часть процесса сборки, что делает это очень простым.Сервер сборки может оповестить программиста о своем проступке (Плохой программист! Файл с плохим отступом! Вам не нужен пончик!) И техническому руководителю или менеджеру сборки.

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

Answer 3

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

Раздел атрибутов Pro Git Book

надеюсь, это поможет.

Answer 4

Это звучит как работа для вашего IDE или редактора XML.Eclipse, например, позволяет вам задавать различные автоматические действия при сохранении (но делает плохой редактор XML) ... Я уверен, что есть редактор XML, который будет приводить в порядок или переформатировать ваш XML для вас при сохранении.

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

В зависимости от команды, с которой вы работаете, и если это «приведение в порядок» кардинально меняет каждый файл, к которому вы прикасаетесь, вы можете избежать этого, или это может быть совершенно нормально.Например, у меня есть конечный пробел в Eclipse и добавляются отсутствующие аннотации @Override при сохранении, но я не говорю ему полностью переформатировать мои файлы .java при сохранении.

Answer 5

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