Проблема организации Svn

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 является лишь немного беспорядок, у меня нет реальный способ создания bracnh только для одного приложения, например . Создание релизов для чего-либо представляет собой огромную боль из-за путей к файлам, используемых приложением. Например, программа python должна знать, где находится dll python extension, и где каждая из общих DLL. Эти пути очень отличаются от svn от того, что они будут для выпуска (где все они похожи в общем каталоге)

Answer 1

Eurrghh!

Разделите все на отдельные проекты/библиотеки DLL/библиотеки/артефакты - все, что вы хотите назвать их и следовать рекомендованной 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: внешние свойства в вашем хранилище в/Application1 /:

svn://repositoryname/LibraryX/buildoutput/ dll 

Когда вы заказываете приложение 1, вы получите все его файлы, плюс он добавит в вашу рабочую копию папку с именем dll, которая будет извлечена из библиотекиX/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 

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

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

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

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

Answer 2

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

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

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

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

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