.net - 使所有 Visual Studio 项目与库保持同步

Question

场景

我有一个包含项目 A、B 和 C 的库。

我有两个解决方案。解决方案 1 包括项目 A 的副本，解决方案 2 包括项目 A 和 B 的副本。

当我构建解决方案 1 时，应该发生以下情况:




当我构建解决方案 2 时，应该发生以下情况:




我怎样才能做到这一点？

这是我可以使用版本控制系统或现成的文件同步软件自动化的东西吗？还是我需要推出自己的解决方案？

如果我确实构建了自己的解决方案，我对它如何工作有一些想法，但我很感激您的任何意见:

可能是一个简单的控制台应用程序，带有用于指定“源解决方案”的命令行开关，例如:

c:\Program Files\Library Syncronizer\LibSync.exe /solution:Solution 1

用于注册包含库项目的事件解决方案的 XML 文件。可能的格式:

<solutions>
  <solution>
    <name>Solution1</name>
    <path>c:\...\Projects\Solution 1</path>
  </solution>
  <solution>
    <name>Solution2</name>
    <path>c:\...\Projects\Solution 2</path>
  </solution>
  <!-- more solutions -->
</solutions>

程序将执行以下操作:

阅读源码解决方案

确定它有哪些库项目

将这些项目的文件夹复制到库

循环遍历 XML 文件中的每个解决方案(源除外)

根据需要复制所有库项目的文件夹

也许也可能会发生一些备份操作，以防同步过程覆盖一些重要的东西。

这在概念上听起来相对简单，但这可能会产生我没有想到的严重意外后果。如果确实如此，希望有人会警告我:)

更新 - 我复制项目文件夹的动机是什么？

一句话—​​—版本控制。

如果我将库项目保存在一个单独的文件夹中，并且只在我的各种解决方案中链接到它们(而不是在我的解决方案文件夹中物理定位文件夹)，我的版本控制存储库最终不包含我的库项目的源代码。因此，如果我更新到“三个版本之前”，并且我需要对我的库方法之一进行小幅更改，则代码不存在。

我的解决方法是在我的库的存储库中的修订中添加标签，这些标签说的是“解决方案 1 - 版本 2.5.3”，但这非常笨拙。如果我正在处理解决方案 1 的“三个版本之前”和解决方案 2 的当前版本，事情会变得非常尴尬。现在，解决方案 2 将指向库项目的旧版本，这使得它可能无法使用并测试，直到我完成解决方案 1 的旧版本的工作。

如果我改为使用副本，则所有解决方案都将在其存储库中包含库源代码，并且我可以随时轻松地返回到它。

我应该在这里注意，我一直在使用 Tortoise HG (Mercurial) 进行版本控制。

无论如何，我对这个问题的任何解决方案持开放态度。它不必涉及复制项目文件夹——这只是我能想到的唯一方法来确保我的所有版本控制存储库都是完整的、独立的包。

更新 2

首先，只是一个注释。我使用 Mercurial (TortoiseHG) 进行版本控制，而不是 SVN。如果绝对必要，我可以更改，但我真的更喜欢 Mercurial。

根据目前的回复，我决定放弃“双向复制”的想法，并重新引用我的图书馆项目。这是一个新的图表:



然而，我仍然有相同的目标:

每个解决方案的最新版本都使用最新的库代码

每个存储库一个解决方案/应用程序

每个存储库都包含所有源代码，包括库项目

一切都尽可能自动化，以最大程度地减少错误风险

目标 #1 是通过引用库项目而不是使用副本来自动处理的，目标 #2 只是我如何设置存储库的问题，但目标 #3 和 #4 仍然难以捉摸。

使用 Mercurial，有一个 subrepositories feature这似乎可以处理我的情况，但正如文档所示，这仍然被认为是实验性的/有风险的。

目前，我认为一个好的解决方法可能是将库项目的备份副本存储在我的解决方案文件夹中。当我说“备份副本”时，我的意思是字面意思。我仍然会引用库项目——这些副本只是为了确保所有源代码最终都在我的存储库中(目标 #3)。为了满足目标 #4，这些备份可以使用工作室中的后期构建事件来自动化。

我欢迎您对此提出任何想法。

Answer 1

这听起来很像 sub repository support在 mercurial 是为了。如果项目 A 和项目 B 等是单独的存储库，您可以将它们设为解决方案 1 和 2 中的子存储库。.hgsub 1 和 2 中的文件本身是版本化的，并指向 A、B 和 C 中的特定修订版，因此您始终可以在每个解决方案中使用相同的版本进行构建，但无需使它们保持同步。将更改从解决方案移回库变得很容易，并且如果需要，还可以分支。

不要让维基页面上提到的“1.3 中的测试版”欺骗了您。 Mercurial 现在是 1.4.2，并且子存储库保持原样。