Существует ли альтернатива.NET для репозиториев артефакта Java как Nexus или Artifactory? То, где Вы храните, присвоило версию DLL?
Где сохранить двоичные файлы, необходимые для автоматических сборок в Системе Команды? Вы еще храните их наряду с кодом в SCM или где-нибудь? Имеет большое количество двоичных файлов в SCM порождение каких-либо проблем производительности с исходным управлением?
Существует потребность смочь вернуться к более ранней версии некоторой внешней библиотеки для исправления ошибок в выпущенной версии, однако версии не совместимы. Ветвление добилось бы цели, но я думаю, что хранение двоичных файлов наряду с кодом является антишаблоном.
Любые suggetions приветствуются.
3 ответа
Мы всегда хранили внешние бинарные зависимости вместе с исходным кодом, образами, сценариями сборки и всеми другими артефактами, необходимыми для создания решения, в системе контроля версий (VCS). Это то, в чем VCS действительно хороша, и она гарантирует, что у нас есть правильная версия всех необходимых артефактов, доступных для любой версии нашей сборки, даже для ветвей.
Мне любопытно: почему вы считаете это анти-паттерном?
Subversion, например, имеет svn: externals , который можно использовать для импорта содержимого другого каталога с ваши библиотеки. Внешний может быть прикреплен к определенной ревизии. Для меня это лучший способ, и вы избегаете вложенных рабочих копий .
Раньше я всегда использовал svn: externals для этого, как описано в съеживается . Но в локальной рабочей копии медленно обновляется. Я начал проект с открытым исходным кодом с парой друзей, чтобы попытаться решить эту проблему, которая все еще находится на очень ранней стадии, но если это проблема, которая вас интересует, вы можете присмотреть за ней (или даже помочь с этим). Он называется Refix и размещен на CodePlex .