Что представляет собой действительное сообщение SCM?

Question

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

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

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

Кстати, вам не нужно беспокоиться о ссылках на рабочие элементы или об ошибках в данном конкретном случае.

Answer 1

Честно говоря, я считаю, что любые конкретные критерии в качестве жесткого требования абсолютно бесполезны. Если вы когда-либо видели веб-сайт, для которого требуется минимальное количество символов в обзоре / комментарии (возможно, на Дракстреме, и даже этот сайт), вы быстро поймете, что эффект не тот, который вам нужен. Вместо того чтобы люди гарантировали, что отзывы и комментарии будут длиннее, они просто найдут больше наполнителей, чтобы убедиться, что они достигли известных и жестко закодированных минимумов.

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

Это все еще не решит проблему на 100%, но это самый близкий подход к работе, который я нашел.

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

Answer 2

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

Поэтому я предлагаю следующее:

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

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

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

Answer 3

Я согласен с другими ответами. Люди, не желающие сотрудничать, всегда найдут способ обойти ваши правила.

Однако я всегда делаю следующее:

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

Answer 4

Я обнаружил, что требование по крайней мере 15 символов (без пробелов) работает достаточно хорошо. Не пытайтесь переусердствовать с более сложными проверками. Настройка списка рассылки commit также поможет; он рекламирует хорошие примеры и добавляет социальный контроль.

Всегда найдется несколько разработчиков, которые воспримут это как вызов, чтобы минимизировать любую полезную информацию в своих сообщениях фиксации. Но если я посмотрю журналы SVN до (на 90% пустые) и после (на 80% несколько полезных) ловушки перед фиксацией, то установлю, что ситуация улучшилась

Answer 5

Это, вероятно, не даст вам много. Если вы отклоните «обновление», то люди просто придумают что-то, что внесет их коммит. «Добавлен новый fizzleglorb в saldkj dot quux». Технические решения социальных проблем не работают.

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