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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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