.NET 项目的良好目录布局，具有跨应用程序使用的库并使用 Mercurial

Question

我一直在使用 Mercurial 来完成一系列独立项目。但现在我正在考虑将 subversion 存储库转换为 Mercurial，这要繁忙/复杂得多。

给出大约 40 个库项目和大约 20 个应用程序（各种 web / console / wpf 等）左右。各种应用程序使用各种库。所有这一切都是在颠覆中的 1 个主干下构建的。因此，有一个目录是所有库所在的目录，还有一个目录是所有应用程序所在的目录。创建新的 Visual Studio 项目时很容易找到和引用库。

简化...

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

现在转向 Mercurial，这不太理想，似乎处理这个问题的方法是为每个应用程序使用 1 个存储库？以及您想要使用的每个库的子存储库？

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

这是对的吗？

如果是这样，当在 Visual Studio 中启动新应用程序并且您想要添加各种库时，最好/最有效的方法是什么？

我感觉初始设置有点痛苦？与颠覆布局相反，实际上，除了在视觉工作室项目中引用库之外，您实际上不需要做任何事情。

因此，因此出现了这个问题，想要了解一个好的目录结构，以及如何使用该结构快速设置一个新项目。

Answer 1

理想情况下，这将基于我自己在处理更大的、不同的应用程序时的观点和经验，但是对于依赖关系，您希望每个不同的、不相关的项目都有一个存储库，并将相关的、可能依赖的项目保留在同一个存储库中。我不是子存储库的忠实粉丝，但这可能只是因为缺乏曝光。

这样做的原因是您应该将相关项目放在一起进行版本控制，因为更改一个项目可能会影响另一个项目。实际上，任何可以纳入单个解决方案并具有项目参考的内容，您肯定都希望保留在一起。

现在，有一些例外情况，您可能有一个库项目，您不一定将其作为解决方案的一部分，但它是一组项目的参考。这是我将 lib 文件夹与同一存储库中的其余应用程序一起保存版本的地方，但 lib 文件夹包含预构建程序集。它还可以容纳第 3 方供应商组件。与使用它们的项目一起进行版本控制也很重要，因为您可以将主项目的库更新视为次要版本。

对于真正独立的其他项目，请为其创建另一个存储库，因为它将有自己的版本生命周期，并且您不希望对它的更改影响其他完全不相关的项目的更改图。

包含多个相关项目和 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

但实际上，您的文件夹结构并不像确保正在运行的项目那么重要被视为一个逻辑单元（产品）并保持在一起，以确保对构建和发布的内容进行控制。这是我对存储库应包含的内容的定义，也是我用来考虑如何在存在多个版本控制产品的情况下拆分内容的定义。