subversionsvncollaboration

Лучшая практика: среда для совместной работы, каталог Bin, SVN

просмотры: 3.2K

Каковы лучшие практики для проверки каталогов BIN в среде совместной разработки с использованием SVN? Следует ли исключить ссылки на уровне проекта из проверки? Проще просто добавить все каталоги bin?

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

Конечная цель (конечно) - заставить нового разработчика проверить транк из SVN, восстановить базу данных DNN и заставить все это просто «работать» ...

Источник

Ответов (5)

Решение

Любые собрания, которые, как ожидается, будут в GAC, должны оставаться в GAC. Это включает System.web.dll или любую другую стороннюю dll, которую вы развернете в GAC в процессе производства. Это означает, что эти сборки придется устанавливать новому разработчику.

Все остальные сторонние сборки должны быть ссылками через относительный путь. Моя типичная структура:

-Project
--Project.sln
--References
---StructureMap.dll
---NUnit.dll
---System.Web.Mvc.dll
--Project.Web
---Project.Web.Proj
---Project.Web.Proj files
--Project
---Project.Proj
---Project.Proj files

Project.Web и Project ссылаются на сборки в папке root / References относительно. Эти .dll проверяются на подрывную деятельность.

Помимо этого, * / bin * / bin / * obj должен быть в вашем глобальном пути игнорирования.

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

Источник

Tree Surgeon - отличный инструмент, который создает пустое дерево разработки .NET. За годы использования он был изменен, и в нем реализовано множество передовых практик.

Источник

Это конкретный вопрос .Net?

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

Если bin каталог, о котором вы говорите, содержит сторонние двоичные файлы, а не сборку вашего проекта, проигнорируйте (отрицательный?) Этот совет.

Источник

Maven очень помогает с этой проблемой, когда я кодирую java. Мы передаем pom.xml в scs, а репозиторий maven содержит все наши зависимости. Для меня это хороший способ сделать это.

Источник

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

Источник