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

dev*_*xer 12 .net version-control mercurial projects-and-solutions visual-studio

脚本

我有一个包含项目A,B和C的库.

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


当我构建解决方案1时,这是应该发生的事情:

替代文字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
    
    Run Code Online (Sandbox Code Playgroud)
  • 用于注册包含库项目的活动解决方案的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>
    
    Run Code Online (Sandbox Code Playgroud)
  • 计划将执行以下操作:

    • 读入源解决方案
    • 确定它具有哪些库项目
    • 将这些项目的文件夹复制到库中
    • 循环遍历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. 一切都尽可能自动化,以尽量减少错误的风险

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

对于Mercurial,有一个子库存功能似乎可以处理我的情况,但正如文档所示,这仍然被认为是实验/风险.

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

我欢迎你对这一点的想法.

Ry4*_*ase 2

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

不要让 wiki 页面上提到的“1.3 中的测试版”欺骗了您。Mercurial 现在已更新至 1.4.2,子存储库保持原样。