Структура папок и автоматическое построение из этой структуры - PullRequest
Новая
       36

Структура папок и автоматическое построение из этой структуры

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

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

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

Мы придумали две структуры папок, и я хотел знать, в чем заключаются преимущества и недостатки каждой из них: 

Projects
  |-> Trunk
    |-> Data Access
    |-> Business
    |-> Desktop
    |-> Website
  |-> Branches
    |-> Branch 01
      |-> Data Access
      |-> Business
      |-> Desktop
      |-> Website

и 

Projects
  |-> Data Access
    |-> Trunk
    |-> Branches
      |-> Branch 01
  |-> Business
    |-> Trunk
    |-> Branches
      |-> Branch 01
  |-> Desktop
    |-> Trunk
    |-> Branches
      |-> Branch 01
  |-> Website
    |-> Trunk
    |-> Branches
      |-> Branch 01

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

<path>$\Projects\trunk\</path>

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

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

<path>$\Projects\*\trunk\</path>

если некоторые проекты были разветвлены, а другие нет, как я могу получить транк, когда ветки не существует (если это возможно).

будет ли получать все стволы с последующей перезаписью с ветками работать? это просто ошибка, если он попытался получить доступ к несуществующей ветви?

Ответы [ 3 ]

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

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

Я вижу несколько проблем со второй методологией:

  1. все проекты должны быть разветвлены / помечены одновременно
  2. Слияние должно быть сделано для каждого проекта в отдельности

Возможны оба варианта, но я считаю, что 1-й вариант является самым простым, но и самым безопасным вариантом.

Поскольку веб-сайт, скорее всего, не зависит от выпусков (если вы выпускаете из ветки, созданной в 2007 году, вы берете не сайт 2007 года, а 2009 год). 

Project
  |
  +- Trunk

Website
  |
  +- Trunk
0 голосов
/ 19 ноября 2009

Я предпочитаю мелкозернистые, очень организованные, автономные, структурированные репозитории. Существует диаграмма , иллюстрирующая общий (идеальный) подход процесса обслуживания хранилища. Например, моя первоначальная структура репозитория (должна быть у каждого репозитория проекта): 

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases
0 голосов
/ 26 марта 2009

В конце я написал плагин управления исходным кодом (используя API Vault), чтобы я мог указать некоторые дополнительные функции в теге <folder>: 

<folder>$/branches/%latest%</folder>

извлечет самую последнюю ветку в папке ветвей.

...