Исходный контроль строит филиал - PullRequest
Новая
       32

Исходный контроль строит филиал

2 голосов
/ 23 марта 2009

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

У меня есть общее представление о том, как выполнить ветвление, но я не уверен, как наша сборочная машина (CruiseControl.net) может получить ветку для ее сборки.

У нас есть много проектов, на которые все полагаются другие проекты (есть и другие): Утилиты> Доступ к данным> Бизнес-логика> Общий графический интерфейс> (Веб-сайт | Клиенты рабочего стола)

Как мы структурируем хранилище (хранилище, если это имеет какое-то значение), чтобы сборочная машина могла:

  1. Сборка сундука
  2. Сборка "последней" ветки

Было бы неплохо иметь грубую структуру папок и / или объяснение того, как получить из cruisecontrol.

спасибо

Edit:

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

Ответы [ 3 ]

2 голосов
/ 24 марта 2009

Решение, предложенное Марком, хорошо работает, если проекты имеют разные циклы выпуска (у Проекта 1 есть версия 1.0, а у Проекта 2 уже версия 1.1). Если бы все ваши проекты были взаимозависимыми, я бы начал с простой структуры 

My Big Project
  | 
  +-- trunk
  |     |
  |     +-- utils
  |     |
  |     +-- data
  |     |
  |     +-- business
  |     |
  |     +-- gui (web)
  |     |
  |     +-- gui (swing)
  | 
  +-- branches
  | 
  +-- tags

Таким образом, вы уверены, что у вас есть ветвь все (весь код), когда вы делаете ветку / тег. В противном случае вы всегда рискуете пропустить один проект при добавлении тегов.

Ваш сервер сборки просто извлечет ствол (со всем) или один тег / ветвь (также со всем) и соберет / установит релиз.

Как только пакет utils стабилен, вы всегда можете «обновить» его до одноуровневого проекта и использовать Maven / Ivy для управления зависимостями.

2 голосов
/ 23 марта 2009

Что вы подразумеваете под «последней веткой»? Ветви должны использоваться для расширенного отклонения за пределами магистрали - магистраль должна всегда содержать последний производственный код.

Каждый проект должен иметь папки trunk и branches: 

Project 1
  |-> trunk
  |-> branches
Project 2
  |-> trunk
  |-> branches
    etc.

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

checkout project1/trunk /builds/project1
build /builds/project1

и 

checkout project1/branches/myBranch /builds/project1
build /builds/project1
0 голосов
/ 25 апреля 2009

Просто чтобы уточнить, как теги и ветви будут использоваться в схеме Владимира. Допустим, версия 1.x вашего продукта вышла из употребления, версия 2.1 вышла в свет, а вы работаете над версией 3.0: 

trunk <- you're working on version 3.0 here
 project1
 project2

branches
 ReleaseBranch-1.0
 ReleaseBranch-2.0 <-- fixes to version 2.1 (the current production version) get committed here, then merged into the trunk

tags
 Release-1.0 <-- a copy of the source that was used to build version 1.0
 Release-1.1
 Release-1.2
 Release-2.0
 Release-2.1

На вашем сервере непрерывной интеграции / сборки вам потребуется 2 процесса:

  • тот, который указывает на транк в вашей системе контроля версий
  • тот, который указывает на ReleaseBranch-2.0 в вашей системе контроля версий

Книга Прагматический контроль версий с Subversion предназначена для Subversion, но в ней рассказывается, как организовать хранилище, как описано выше.

...