【问题标题】:Visual Studio, svn and merging .csproj and .sln filesVisual Studio、svn 和合并 .csproj 和 .sln 文件
【发布时间】:2009-08-25 16:42:06
【问题描述】:

是否有人成功让 SVN 合并由两个用户编辑的 Visual Studio 项目 (.csproj) 或解决方案 (.sln) 文件?示例

  1. 用户 A 签出项目
  2. 用户 B 签出同一个项目
  3. 用户 A 添加文件
  4. 用户 A 提交更改
  5. 用户 B 添加文件
  6. 用户 B 提交更改

在我看来,在步骤 (6) 中,svn、Tortoise、Ankh 或任何应该检测到冲突的东西,要么自动合并两个项目文件,要么更有可能提示用户 B 解决冲突。目前,我们看到用户 A 所做的更改在用户 B 签入时被抹杀,导致构建、部署等错误,导致上次签入之前添加的功能丢失。

既然项目文件是 XML,为什么这是个问题?我在这里错过了什么吗?我已经搜索了这里的档案并用谷歌搜索了我不能再用谷歌搜索了,但还没有想出一个好的解决方案。

【问题讨论】:

  • 您是否在文件上正确设置了 MIME 类型?
  • 用户 B 的提交应该被拒绝,因为他的文件已过期,迫使他更新(并合并——大多数更改确实是自动处理的)。
  • 是的,在第 6 步,svn 客户端应该报告工作副本已过期。一定是哪里出了问题,因为这对我们有用。
  • 如果用户 A 和 B 位于不同的功能分支上,并且通过将项目添加到解决方案(而不是将文件添加到项目)来做到这一点,我肯定会发生这种情况。不过,这可能是一个单独的话题……

标签: visual-studio svn merge


【解决方案1】:

您认为您是如何欺骗 SVN 执行第 6 步的?看来你误解了哪里出了问题。 SVN 永远不会从不是最新的工作副本提交,因此如果用户 B 之前没有更新和合并用户 A 的更改,步骤 6 将无法工作。诚实地。试试看。

我猜想发生的事情是这样的:

  1. 签出项目。
  2. B 签出同一个项目。
  3. A 添加文件。
  4. A 提交更改。
  5. B 添加文件,但忘记保存项目/解决方案。
  6. B 尝试提交更改并收到一条他应该首先更新的消息。
  7. B 更新。
  8. B 切换回 VS。 VS 告诉他磁盘上的项目/解决方案已更改,并询问他是否要 a) 从磁盘重新加载并丢失更改 b) 覆盖磁盘上的版本。
  9. B 不理解,不尝试理解,认为他的更改有价值,并选择 b),覆盖磁盘上的更改。
  10. B 仍然没有尝试理解,因此不会将他在磁盘上的版本与最后提交的版本进行比较,因此错过了他覆盖 A 的更改。
  11. B 签入,覆盖 A 的更改。

我偶尔会看到这种情况发生,通常是用户 B 并不真正了解 SVN(或 CVS',FTM)的工作流程。

所以这里有一些提示:

除非您已保存所有内容,否则请勿更新(“文件”->“全部保存”;对我来说,就是 Ctrl+Shift+S)。如果您犯了这个错误并且卡住了,请覆盖磁盘上的更改,然后手动合并丢失的更改。 (也可以将项目/解决方案文件更新回版本 N-1,然后再次更新到 HEAD,以便让 SVN 执行合并。)

不要在未检查您更改了哪些文件并快速查看差异的情况下提交看看这些变化是否是你所期望的。

尽早提交,经常提交。使用相同代码库的开发人员越多,发生冲突的可能性就越大。您更改工作副本而不更新的时间越长,发生冲突的可能性就越大。由于开发人员的数量通常不在您的控制范围内,因此更新频率是您可以用来降低冲突概率的一件事。

【讨论】:

  • 这听起来很熟悉。这可能更像是一个培训问题而不是技术问题。 =/
【解决方案2】:

我支持 sbi 的回答。一种可能的解决方案是始终从 Visual Studio 中更新,至少在您使用 VisualSVN 的情况下(我不确定 AnkhSVN 如何应对这种情况)。

VisualSVN 会在更新操作过程中阻塞visual studio,并确保任何更改的项目都会自动重新加载,因此用户不能忽略外部更改。

【讨论】:

    【解决方案3】:

    一个相当激进但有效的解决方案是使用一种工具从元定义生成这些解决方案文件,然后只将元定义置于源代码控制之下,而不是 Visual Studio 项目文件(合并是一场噩梦)。

    在我的团队中,我们使用MPC 来执行此操作。我们有:

    • 一堆用于项目描述的 .mpc 文件,
    • 用于工作区/解决方案描述的 .mwc 文件,
    • 用于生成 Visual Studio 文件的小 .cmd。

    由于它们都是手工编辑的文本文件,我们不再遇到 Visual Studio 混淆所有内容的问题。

    缺点是一个额外的工具,并且在添加或删除文件时需要重新生成解决方案文件,但也有一些额外的好处:

    • 项目配置是集中的:例如,更改编译标志是在一个地方完成的,而不是基于每个项目,
    • 这可以容纳多个构建系统(我们目前使用 Visual 2003 和 2005,但这也适用于 gcc 和其他系统)。

    根据我的经验,尽管设置工具可能有点痛苦(但这完全取决于项目的规模和复杂性),这显然是值得的。

    请注意,MPC 并不是用于此目的的唯一工具。其他存在,例如CMake

    【讨论】:

      【解决方案4】:

      您还可以通过确保您的项目文件不列出项目中的每个单独文件来尝试减少冲突。这将避免在用户添加文件时首先更改项目文件。

      您可以在项目文件中随意使用通配符:see MSDN

      例子:

      <ItemGroup>
        <Compile Include="Src\**\*.cs" />
        [...]
      </ItemGroup>
      

      很遗憾,Visual Studio 不鼓励这种项目设置,而是选择列出单个文件。

      【讨论】:

        【解决方案5】:

        这是非常乏味且令人厌烦的,因此您只需要努力完成即可。您有时会保留本地工作副本,因为它添加了所有自定义项目。但是,在其他情况下,您将希望合并基本解决方案中的所有新项目,以便最终得到两个解决方案文件中的所有内容。为了便于阅读,最好将所有基础产品添加放在自定义添加之前。

        不要担心 GUID 的第一部分对于项目是相同的,但它是唯一的最后一部分。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2016-08-31
          • 2011-04-21
          • 1970-01-01
          • 1970-01-01
          • 2017-08-06
          • 2010-09-12
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多