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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

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