Как поощрять более частые коммиты в SVN

Question

Группа разработчиков, с которыми я работаю, перешла с VSS на SVN около полугода назад. Переход от CheckOut-CheckIn к Update-Commit был трудным для ряда пользователей. Теперь, когда они больше не вынуждены проверять свои файлы, когда они сделаны (или точнее, теперь, когда никто больше не может увидеть, что у них есть файл, извлеченный и сказать им, чтобы проверить снова, чтобы снять блокировку на файл), это происходило не раз, когда пользователи забыли зафиксировать свои изменения до тех пор, пока они не были завершены.

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

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

Приветствуются готовые решения (то есть: настольная программа, которая напоминает пользователям о коммитах, если они не сделали этого в течение заданного интервала, автоматически получает статистику пользовательских коммитов и отправляет предупреждающие электронные письма, если частота падает ниже определенного порог и т. д.).

Answer 1

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

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

Если разработчики просто занимаются своими делами без ответственности, то неудивительно, что вы сталкиваетесь с проблемами, заставляющими всех сотрудничать. Вам понадобится какой-то надзор (руководитель проекта? Руководитель группы?), Который отвечает за то, чтобы отдельные разработчики сотрудничали с остальной частью команды разработчиков.

Answer 2

Если вы ранее использовали VSS, вы, вероятно, работаете в Visual Studio. AnkhSVN имеет окно ожидающих изменений, как в TFS и VSS. Это окно инструментов автоматически показывает, какие файлы локально изменены в вашем решении.

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

[Смотрите этот скриншот более старой версии AnkhSVN]

Answer 3

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

Автоматизируйте сборку и развертывание и сделайте его частью процесса, который ничего не "делает", пока он не будет протестирован на тестовом сервере

Answer 8

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

Звучит так, будто что-то в корне не так. Как ваш разработчик вносит свои изменения в выпущенный продукт, не проходя через VCS? Ты должен закрыть эту заднюю дверь.

Answer 9

Приличный трекер ошибок / функций позволит вам добавить номер ошибки, когда вы фиксируете свои изменения. Например, если я использую Redmine, я могу зафиксировать с помощью «Fixes # 323» где-нибудь в моем сообщении о фиксации Subversion, и оно автоматически закроет ошибку / задачу 323. Его настройка очень проста; Вы просто должны сообщить Redmine, где находится хранилище, которое в любом случае запрашивается.

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

Трак тоже делает это, как и многие другие.

Answer 10

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

Как разработчик может что-то закончить и забыть проверить? Процесс доставки таков, что пользователь запускает сборку с собственной машины разработчика?