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

Question

Какое общее правило? Когда вы совершаете?

Answer 1

Фиксируйте рано и часто. Это минимизирует шаги по разрешению конфликтов при работе в команде. Но не совершайте ничего, что нарушает вашу сборку. В идеале непрерывная интеграция уведомляет команду, когда сборка прерывается.

Answer 2

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

Answer 8

Общее правило:

• после внесения атомных изменений, которые имеют смысл.

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

Имеет смысл: он включает безопасное обновление - компилирует и не нарушает функции - что имеет логическое изменение, которое вы не боитесь сказать в комментарии.

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

Еще несколько полезных практик можно найти здесь: http://ducquoc.wordpress.com/2011/06/09/svn-best-practices/

Answer 9

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

Answer 10

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

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