поиск рекомендаций для CM МЕТОДОЛОГИЯ разработки малых проектов с SVN - PullRequest
1 голос
/ 23 декабря 2009

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

Я знаком с CVS и читаю введение в SVN, это не имеет большого значения. Меня интересуют ссылки на методологию CM , которая позволит нам затрачивать наименьшие усилия на CM как таковую, но позволит нам работать без сбоев. Я уверен, что нет необходимости заново изобретать колесо, я просто хочу подтвердить идею, которая у меня есть.

Что я имею в виду:

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

Мне неясно:

  • мы должны начать новую частную ветку из сундука или работая на том же частном ветка разработки?
  • Я вижу, что у SVN особое поведение при реинтеграции обратно конкретно на багажник . Здесь преимущества (или недостатки) в наличии специальная ветка интеграции, тогда?

Большое спасибо.

Ответы [ 2 ]

4 голосов
/ 23 декабря 2009

Почему вы чувствуете необходимость заниматься разработкой в ​​частных филиалах? Разве вы не можете заставить своих разработчиков работать вместе, по одному и тому же пути к хранилищу? Причина, по которой я спрашиваю, заключается в моем опыте: большинство людей, которые думают, что им «это нужно», обычно ошибаются и не понимают управление исходным кодом и то, как работает Subversion. Я не обвиняю вас в этом, но я надеюсь, что вы сможете объяснить причину этого требования, поскольку оно может повлиять на будущие предложения.

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

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

1 голос
/ 27 декабря 2009

Я бы начал только с магистральной ветки с ветвями обслуживания для выпусков, если это необходимо. Обычно это хороший вариант по умолчанию. Это приведет к неожиданно малому количеству конфликтов и будет стимулировать развитие к «частым изменениям», что хорошо. Я испытал это с размером команды 1-10 разработчиков, и это работает. Это называется "ветвями релиза" в Subversion doc.

Функциональные ветви - еще один распространенный способ работы. Здесь вы создаете новую ветвь для каждой новой функции и объединяете функции обратно в транк. У одного разработчика может быть несколько ветвей функций одновременно, или несколько разработчиков могут одновременно работать с одной и той же веткой функций.

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


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

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

Однако в ветке trunk нет ничего особенного, это нормальная ветка во всех отношениях. У него просто другое название, чем у других веток. Таким образом, нет особого отношения к реинтеграции в магистраль . Документы Subversion говорят о --reintegrate операции, но это относится к следующему случаю:

  1. У вас есть ветвь A (во многих случаях это будет магистраль )
  2. Вы создаете новую ветку B из ветку A
  3. Вы модифицируете ветвь B и, возможно, также ветвь A
  4. Вы объединяете или реинтегрируете изменения с ветви B до ветви A .
...