应用错误收集

方案

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

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

当我构建解决方案1时，以下是应该发生的事情：

alt text http://img689.imageshack.us/img689/9341/onbuildsolution1.jpg

当我构建解决方案2时，应该会发生什么：

alt text http://img32.imageshack.us/img32/7821/onbuildsolution2.jpg

我该怎么做？

这可以通过版本控制系统或现成的文件同步软件实现自动化吗？或者我需要推出自己的解决方案吗？

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

可以是一个简单的控制台应用程序，带有用于指定“源解决方案”的命令行开关，例如：
```
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。

根据到目前为止的回复，我决定取消“双向复制”的想法，然后回到引用我的图书馆项目。这是一个新图表：

alt text http://img30.imageshack.us/img30/7445/referencedprojects.jpg

但我仍然有相同的目标：

每个解决方案的最新版本都使用最新的库代码
每个存储库一个解决方案/应用程序
每个存储库包含所有源代码，包括库项目
一切尽可能自动化，以尽量减少出错的风险

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

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

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

我对你的任何想法表示欢迎。

考虑为什么您的应用程序需要使用不同版本的库。如果你正确地设计你的库，并确保你在升级它们时不会破坏任何东西（使用持续集成和单元测试，以及测试所有依赖项目）那么在大多数情况下最好（最简单，最干净）的方法就是使所有应用程序都运行相同版本的库。我甚至会说，如果你的应用程序不能运行相同的库版本，那就告诉你你的库没有被正确设计/实现/维护，你应该重新考虑你的方法。

另一种方法是为每个Application使用一个分支，因此每个都有自己的独立的Libraries副本（使用项目和库之间的相对引用，然后你可以重新定位分支中的代码）。这允许应用程序构建不同版本的库，但确实具有分支的所有缺点 - 两个库的副本因此您必须小心不要在错误的分支中编辑;讨厌合并的可能性等等。

我建议将图书馆项目移到图书馆。您的图表显示了应用程序解决方案构建库代码并将其推送到库，然后将构建的库文件吸回到项目中 - 双向副本，eek！只需将库项目放在库中并构建库，然后从项目中引用该库 - 单一副本。您可能认为这意味着您必须构建两个解决方案（库和应用程序），但您可以随时在应用程序解决方案中添加/删除库项目，因此这种布局不需要两阶段构建过程。但是库和应用程序之间的逻辑区别要清晰得多。

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

不要让那个wiki页面上提到的“beta in beta”愚弄你。 Mercurial现在高达1.4.2，并且subrepos保持原样。

我不确定我理解你的“图书馆”的目的吗？

为什么这两个解决方案实际上并没有引用同一个项目而不是副本？

如果目的是能够在“库”的不同分支上工作，那么您所描述的是由SVN等源代码控制软件处理的事情。

你会hava“trunk”（你的图书馆）然后从树干创建两个分支。在适当的里程碑，您将一个分支合并回主干，并将主干合并到其他分支。

抱歉，我没有在此页面上阅读全文。但！简短的回答是： Visual Studio可以完成您想要的所有必要的自动化。

我们有类似的结构。 Solution1，Solution2和包含多个项目的公共库。我们在SVN下的文件夹结构如下：

\myRepository
            \Solution1
            \Solution2
            \CommonLibrary\
                          \Project1
                          \Project2
                          \Project3

正如您在此处可以看到无复制。两种解决方案都只是引用..\CommonLibrary\ProjectX。

在我为存储库执行SVN-Update命令后，Visual Studio会询问我'ProjectX已更改。你想重装吗？我点击“是”继续我的编码。

PS：同时查看此软件http://svnnotifier.tigris.org/它可以自动（通过计时器）或鼠标单击更新任意数量的存储库本地副本。

保持所有Visual Studio项目与库同步

5 个答案: