Лучшие практики для зависимостей от управления исходным кодом
Как Вы обрабатываете установку управления исходным кодом нескомпилированного проекта, который имеет зависимость от отдельной платформы или библиотеки? Например, Спроектируйте Платформу использования B. Проект A должен также включать код от Платформы B в ее репозитории? Существует ли путь к нему, чтобы быть включенным автоматически из другого репозитория, или у меня был бы к обновленному он вручную? Каковы общие подходы, обычно берутся для этого сценария? Предположите, что я управляю репозиториями и для Проекта A и для Платформы B и что исходный код для обоих не компилируется.
Любые ресурсы или предложения значительно ценились бы. Я в настоящее время использую Подверсию (на очень простом уровне), но я хотел бы переключиться на Подвижный так, чтобы я мог испытать Печь для обжига с Fogbugz.
Править: В Подвижном Вы использовали бы родительские репозитории для этой функции?
4 ответа
Если вы хотите использовать Subversion и вам нужно включить код из другого репозитория, Subversion Externals может быть вариантом.
Однако, если вы имеете дело с компилируемым кодом, может быть лучше настроить процесс сборки, который просто выбирает требуемые двоичные файлы. Инструменты сборки, такие как Maven , могут помочь вам в этом.
Большую часть времени я стараюсь включать все необходимое для сборки проекта в subversion. Я использую C# и Visual Studio, поэтому большинство моих зависимостей - это dll. В других средах конвенции могут немного отличаться.
Вот как я обычно составляю новый проект:
- ref
- SomeOpenSourceProject.dll
- SomePurchasedComponent.dll
- MyProjectA
- MyProjectA.csproj (ссылки ..\ref\SomeOpenSourceProject.dll)
- MyProjectB
- MyWeb (ссылки ..\ref\SomePurchasedComponent.dll)
- MyApplication.sln
Таким образом, он может быть проверен и собран новым разработчиком без особых проблем. Раньше они использовали сетевой ресурс для dll, но это раздражало, так как разные проекты использовали разные версии, и если вы хотели вернуться в subversion, ветвление или что-то еще, было трудно уследить за этим. Эта структура прекрасно решает эти проблемы.
Я делаю что-то очень похожее на Дэвида Хога, за исключением того, что это выглядит так:
- lib (anything used IN the software)
- purchased_component.dll
- internal_library.dll
- icon_set
- icon1.ico...
- tools (anything used to BUILD the software)
- nunit.framework.dll
- settings.stylecop
- settings.fxcop
- src (the software itself)
- myapp.sln
Большая часть вдохновения для этой установки пришла из дерева хирург (правда, к настоящему моменту уже устарел)
Если B - проект с открытым исходным кодом, и вы хотите скомпилировать его с A, я бы предложил вам попробовать технику vendor drop. Так вы сможете сохранить свой собственный патч.
Если B - проприетарный код вашей компании, и вы не хотите его компилировать, будет гораздо проще просто скопировать скомпилированные двоичные файлы в репозиторий A.