Как часто программист должен согласиться на SVN?

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

Это освещено (и хорошо освещено) в более ранней публикации о передовых методах.

Лучшие практики SVN - работа в команде

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

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

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

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

Это действительно зависит от ситуации.

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

Обычно, когда Я работаю с ним в своей ветке, поэтому следую 2 рекомендациям

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

Я фиксирую каждый раз, когда выполняю единицу работы: исправлена ​​ошибка, добавлена ​​функция, повышена эффективность и т. д. Но я стараюсь избегать длительного молчания. Совет из Don't Go Dark стоит прочитать.

Зафиксируйте, если у вас есть код, который вы не хотите терять. Это не означает, что вы делаете ставку на ствол, если вы разрабатываете в команде, вам следует избегать поломок для других. Сколько кода вы хотите переработать, если ваш редактор уничтожит файл? Час или два?

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

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

Программисты, работающие с тонкой / распределенной VCS или использовавшие ее ранее, будут фиксировать небольшие изменения или особенности, потому что локальная фиксация очень дешевая. Затем они будут нажимать на центральное репо, как только им понадобится синхронизация. Но поскольку фиксация очень дорога с SVN, программисты, которые используют SVN (обычно), совершают ежедневные фиксации, которые иногда могут быть очень большими, а фиксации могут быть связаны по функциям. Это дурная привычка.

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

What I usually do if I need to add a new feature or fix a bug, is to create a branch from wherever I need to, do my work there, get it code reviewed and than merge it back in. You could even break down your branches folder for each user (may not make sense if you have a lot of users) that each developer would keep their changes in.