Как структурировать репозиторий, состоящий из нескольких библиотек и приложений

Я выиграл задачу реструктуризации / воссоздания существующего репозитория кода, используя Git или Subversion. История репозитория не обязательно важна в этом частном случае. Проанализировав ситуацию, я обнаружил некоторые проблемы с определением хорошего макета. Я прочитал много блогов и тем, но я все еще не уверен, что является лучшим макетом.

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

    +---------->include files
    |                ^
    |                |
library A -----> library B <----- library C <----- library D
  ^  ^                                |                ^
  |  |                                |                |
  |  +--------------------------------+                |
  |                                                    |
application 1        application 2 --------------------+
  ^
  |
script -----> configuration information

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

Я придумал следующую структуру:

trunk/
  include/
  lib/
    library A/
    library B/
    library C/
    library D/
  app/
    application 1/
    application 2/
tags/
  1.0/
    include/
    lib/
      library A/
      library B/
      library C/
      library D/
    app/
      application 1/
      application 2/
  1.1/
    include/
    lib/
      library A/
      library B/
      library C/
      library D/
    app/
      application 1/
      application 2/
  ...

каждый раз, когда я создаю новую версию, я просто копирую весь репозиторий в новый подкаталог в тегах.

проблема с этим решением заключается в том, что библиотеки не имеют отдельных каталогов тегов для себя, и что я только хочу иметь выпуск, состоящий из помеченных компонентов, и это решение не отображает, какие компоненты имеют версии тегов в выпуске. Я рассмотрел возможность использования отдельных репозиториев, а затем создать главный репозиторий, который имеет подкаталог releases, где я связываю все необходимые компоненты с подкаталогом "svn:externals" и определенным подкаталогом тегов, но разные библиотеки и включенные файлы зависят друг от друга, и я не вижу, как разбить код на отдельные сущности.

любой идеи?

=============== вопрос продолжался 28-1-2011 ===============

хорошо, я нарисовал график того, как я планирую новый макет. Цель состоит в том, чтобы связать теги различных зависимостей с помощью метода svn: externals в пределах одного репозиторий, например, я бы установил svn: externals в багажник/проекты/Либ/library2/зависимостей ^/теги/проекты/включить/СТД/1.3.

trunk/
  projects/
    include/
      std/
    lib/
      library1/
        dependencies/
          std/ --> tags/projects/include/std/1.2
      library2/
        dependencies/
          std/ --> tags/projects/include/std/1.2
          library1/ --> tags/projects/lib/library1/1.4.3
      library3/
        dependencies/
          std/ --> tags/projects/include/std/1.3
          library1/ --> tags/projects/lib/library1/1.4
    app/
      application1/
        dependencies/
          library3/ --> tags/projects/lib/library3/1.1
      application2/
        dependencies/
          library1/ --> tags/projects/lib/library1/2.1
      application3/
        dependencies/
          std/ --> tags/projects/include/std/1.2
          library2/ --> tags/projects/lib/library2/1.5.2
    config/
      configuration1/
        dependencies/
          application1/ --> tags/projects/app/application1/2.3
      configuration2/
        dependencies/
          application1/ --> tags/projects/app/application1/1.6
      configuration2/
        dependencies/
          application2/ --> tags/projects/app/application1/1.6
tags/
  projects/
    include/
      std/
        1.2/
        1.3/
    lib/
      library1/
        1.4.3/
        1.4/
        2.1/
      library2/
        1.5.2/
      library3/
        1.1/
    app/
      application1/
        1.6/
        2.3/
branches/
  ...

оставшиеся вопросы:

• эта конструкция выполнима, или вы видите какие-то существенные недостатки?
• что произойдет, если я скопирую библиотеку в каталог тегов? Это скопирует svn: свойство externals также. Вызовет ли это проблемы или такое поведение желательно?
• я мог бы указать явную ревизию для всех внешних, но тег не должен меняться в любом случае, так что каталог не будет достаточным?
• будет ли репозиторий разделен на репозиторий разработки и репозиторий, использующий svn:external, лучшим решением? См. ответ "Варианты использования" в вопросе каковы преимущества "svn: externals"?.