Наличие dist в управлении источниками может считаться хорошей практикой, если вы хотите, чтобы ваша система управления источниками была уникальной ссылкой для всех:
- 1010 * Разработчики *
- ассемблеры (юнит-тестирование)
- омологационные тестеры (вы запрашиваете кучу dist на своей платформе интеграции и проводите там свои нерегрессионные тесты, perfs тесты, стресс-тесты и т. Д.)
- менеджеры выпуска продукции
...
НО у вас должен быть правильный процесс освобождения, чтобы справиться с этим.
В вашем случае, build должен находиться в отдельном и частном каталоге , то есть каталоге, не входящем в subversion. Когда сборка в порядке, вы импортируете в subversion, если это официальный релиз, или импортируете его в общий каталог, если это временная сборка просто необходим следующей команде (таким образом, избегая сотен сборок в SCM, используя пространство для ничего).
Примечание: главное преимущество наличия доставки (dist) в вашем SCM состоит в том, чтобы зависимый проект работал не с вашими источниками, а напрямую с вашей доставкой (которая является Обязательно в тот или иной момент приступить к работе): если им удастся заставить свой код работать, компилируя с вашей доставкой, шансы их собственного дистрибутива при развертывании с вашей будут работать.
Таким образом, другие команды получают доступ к вашей доставке (ваш «myProject.jar»), когда они получают доступ к любому из своих источников: они могут через SCM прочитать версию вашего jar, его дату, его историю, его метаданные, его метку и и так далее.
Тем не менее, для одного небольшого монолитного (как «ни один другой проект не зависит от него») можно утверждать, что dist (окончательная пакетная поставка) может быть перестроена по требованию и сохранена во внешнем справочная система , например, внешний репозиторий Maven.
НО: Maven не является репозиторием SCM, это означает, что вам нужно подписать свой jar ('MyProject-1.0.jar'), у вас нет истории, и вам необходимо сообщать все свои метаданные в отдельном текстовом файле во время доставки. Любой другой проект, имеющий доступ к этой доставке в этом репозитории Maven, должен настроить свои сценарии и пути к классам в соответствии с соглашением об именах версий.
Кроме того, Maven - это еще один репозиторий в вашей архитектуре разработки. Всякий раз, когда вы можете уменьшить количество репо до минимума ('1';)), это лучше.