Свн организация проблемы

Question

Я не уверен, как организовать эти проекты, так как все они зависят друг от друга.

Прямо сейчас все в следующей структуре, с которой становится все сложнее

-trunk
 |-bin - compiled common dlls
 |-lib - static libs for use with common dlls
 |-src - common dll source code
 |-include - headers for common dlls
 |-common.sln - VS 2008 solutions for common dlls
 |-samples
 ||-res - resources for samples
 |||-img
 |||-snd
 ||-c++ - c++ samples for common dlls, tends to double up as tests
 |||-various VS 2008 sample solutions
 ||-py - python versions for some samples
 |||-...
 |-wrappers
  |-python
  ||-bin - compiled python extension dll
  ||-src - source for python wrapper
  -Apps - actaul programs using common dlls, each with its own dir and solution
  |-...

У этого есть ряд проблем: -1 структура svn - просто беспорядок, у меня нет реального способа создания приложения только для одного приложения, например Создание выпусков для чего-либо - огромная боль из-за путей к файлам, используемых приложением. Например, программе на python необходимо знать, где находится расширение dll для python и где находится каждая из общих dll. Эти пути очень отличаются от SVN от того, что они будут для релиза (где они все, как правило, в общей директории)

Answer 1

Eurrghh!

Разделите все на отдельные проекты / библиотеки / библиотеки / артефакты - как хотите, чтобы они назывались, и следуйте рекомендуемой структуре SVN:

/ (root)
  /Application1
    /branch
    /tag
    /trunk
  /Application2
    /branch
    /tag
    /trunk
  /LibraryX
    /branch
    /tag
    /trunk
  /LibraryY
    /branch
    /tag
    /trunk

Тогда, когда приложение ожидает, что одна из этих библиотек или зависимостей будет находиться в каталоге внутри своей структуры, используйте свойство svn: external для его извлечения.

Например, если вы хотите, чтобы скомпилированная dll из LibraryX находилась в папке с именем dll в Application1, вам нужно добавить следующее свойство svn: external в свой репозиторий по адресу / Application1 /:

svn://repositoryname/LibraryX/buildoutput/ dll

Когда вы извлекаете приложение 1, вы получаете все его файлы, плюс в вашу рабочую копию добавляется папка с именем dll, которая будет извлечена из LibraryX / buildoutput /

Вы также можете проверить каждый проект в своей папке и выбрать некоторые файлы. Но это требует немного другого подхода - все папки с одинаковой родительской папкой на вашем локальном компьютере будут проверены следующим образом:

Application1 (checked out from svn://repositoryname/Application1/trunk)
LibraryX (checked out from svn://repositoryname/LibraryX/tag/stable)

Итак, если вам нужен конкретный файл из результатов сборки LibraryX, вы добавите:

svn:externals ../LibraryX/build/thelibfile.dll libfile.dll

.. как свойство для извлеченной рабочей копии Application1, которая извлекает libfile.dll из LibraryX и помещает его в корень рабочего каталога Application1.

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

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

Вы можете вносить только один внешний файл с версией Subversion 1.6.x

Answer 2

В общем, если у вас есть несколько проектов в хранилище Subversion и он становится грязным, вы хотите сделать одну из двух вещей:
1) Вы объединяете все это в один монолитный проект, потому что все работают над одним и тем же, и, следовательно, теги и ветви применяются ко всему. Это обычно делается, когда одна и та же команда работает над всем кодом, а проекты на самом деле представляют собой просто компоненты, скомпилированные по-другому.

2) Вы разделяете различные проекты на части, помещаете их в свой собственный репозиторий (или, по крайней мере, разделяете их сверху со своим собственным разделом trunk / branch / tag под этим каталогом проекта), и строите их полностью отдельно и публикуете их в хранилище, в данном случае общая файловая система или веб-сервер.

В вашем конкретном случае все выглядит так, как будто у вас есть два проекта, общий набор библиотечного кода и некоторые пользователи этого кода. Таким образом, вы получите структуру верхнего уровня:

1. Apps
2. Common
3. Образцы (Может быть?!)
4. Упаковщики

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