Хорошая структура каталогов для .NET проектов с библиотеками, используемыми в приложениях и использующих Mercurial

Question

Я использовал Mercurial для нескольких автономных проектов.Но сейчас я смотрю на преобразование репозитория Subversion в Mercurial, который намного более занят / сложен.

Учитывая около 40 библиотечных проектов и около 20 приложений (различные web / console / wpf и т. Д.) Или около того.Различные приложения используют различные библиотеки.Все это структурировано под 1 стволом в Subversion.Итак, есть каталог, в котором живут все библиотеки, и каталог, в котором живут все приложения.Очень легко найти и ссылаться на библиотеки при создании новых проектов Visual Studio.

упрощено ....

--trunk-|-- libs
        |-- apps

Теперь переход на Mercurial, это не так идеально, кажется, путьсправиться с этим с 1 хранилище для каждого приложения?и вложенные репозитории для каждой библиотеки, которую вы хотите использовать?

--app repository-|-- libs
                 |-- app

Это правильно?

Если это так, при запуске нового приложения в Visual Studio и если вы хотите добавить различные библиотеки, чтолучший / самый эффективный способ сделать это?

У меня такое ощущение, что начальная настройка немного болезненна?В отличие от макета Subversion, где вам фактически не нужно ничего делать, кроме как ссылаться на библиотеку в вашем проекте Visual Studio.

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

Answer 1

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

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

Теперь, есть некоторые исключения, когда у вас может быть библиотечный проект, который вы не можете обязательно иметь как часть решения, но который является ссылкой для набора проектов. Здесь я бы сохранял версию папки lib вместе с остальными приложениями в том же репозитории, но папка lib содержит сборки перед сборкой. Он также может содержать сборки сторонних поставщиков. Это также важно для создания версий вместе с проектом, который их использует, поскольку вы можете рассматривать обновление библиотеки для основного проекта как вспомогательный выпуск.

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

Пример макета с несколькими связанными проектами и папкой lib:

[-] Big Product Repo
 --[-] Big Product 1
 ----[+] Dal
 ----[+] Services
 ----[-] Web
 ------[+] Controllers
 ------[+] Models
 ------[+] Views
 --[+] Big Product 2
 --[-] lib
 ----[+] iTextSharp
 ----[+] nHibernate

Пример макета с другим проектом, не связанным с ним (для примера, проект служб Windows):

[-] Small Product Repo
--[-] Windows Services
----[+] Emailer
----[+] Task Runner

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