2010-09-04 1 views
1

В настоящее время мы используем Mercurial как наш VCS на BitBucket.Mercurial, Разделить каждый проект в решении?

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

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

Другое главное, как это повлияет на QA? Должны ли они объединить все ветви до строительства?

Я действительно смущен этим.

ответ

2

Как указано в «When should you make a branch», вы используете ветвление, чтобы изолировать усилия по разработке.
В вашем случае вы изолируете каждый проект в решении, на котором вы работаете.
Это позволяет бы для:

  • промежуточных фиксаций, проект по проекту
  • QA тестирование для каждого проекта

Но это также потребует слияния в общей отрасли для всего проекта будет протестированы вместе как решение.

See HgInit (от Joel Spolsky) для получения дополнительной информации о таком рабочем процессе сотрудничества.

alt text

В «Repository архитектуры», Джоэл иллюстрирует два усилия в области развития, изолированных в двух разных команд, но до сих пор в том числе синхронизации (слияния) усилие в конце.

+0

Да, мне удалось найти это после того, как я опубликовал его, но не смог найти его, глядя перед публикацией. Идите фигуру. Вещь, о которой я не знаю, заключается в том, что проектами являются все DLL-файлы, которые загружаются на основе запуска приложения. После выбора пользователя запускается «приложение», которое полностью содержится в указанной DLL, которая представляет собой полностью содержащий проект с winforms и все, что ему нужно. Сказав это, мы небольшая команда из 3 человек, нам нужно поддерживать несколько локальных копий по одному для каждой ветки? –

+0

@Mustafa: если эти DLL могут быть легко созданы (заново) для каждого проекта, они не должны быть версиями в первую очередь. Кроме того, если каждый тестируемый проект должен иметь стабильную версию других проектов, тогда подход, использующий ** Mercurial subrepos **, может быть в порядке (и будет по-прежнему совместим с ветвлением): см. Http: //stackoverflow.com/questions/2083393/mercurial-subrepos-how-do-you-create-them-and-how-do-they-work. – VonC

+0

Ах, я не должен был прояснить ситуацию. DLL сами не отслеживаются, но, очевидно, их источник. Построение решения было бы достаточно. Я рассмотрю идею суб-репо, мне просто нужно проверить, что она может быть реализована на битбакете! Спасибо, чувак, отмеченный как ответил, хотя я могу прокомментировать. –

Смежные вопросы