从svn更新而不自动合并

Question

我的同事对svn更新的工作方式有疑问，但我不确定原因，所以这个问题有两个方面。首先，如何以他想要的方式解决他的问题，其次，我是否应该试着让他相信TortoiseSVN现在做事的方式是最好的方式（如果是的话，怎么做）？

他的理想用例

1. 右键单击 - ＆gt; SVN更新
2. 只要文件在工作副本中没有更改
，SVN就会从存储库中提取更改
3. 如果工作副本和HEAD都发生了变化，他希望在发生任何事情之前得到提示，并自己进行合并（即使这是svn很容易弄明白的情况）。

我想这是一个足够合理的请求，但他不想信任SVN的事实困扰着我，尽管它并没有真正影响我或我的工作。他之前使用的是CVS，SVN和ClearCase，他并不擅长版本控制。他声称他之前能够在svn中做到这一点（同时，他也是我多年的高年级）。

Answer 1

TortoiseSVN常见问题：“prevent subversion from doing automatic merges”。

编辑：我正在复制常见问题解答中的链接答案，以保护此答案免受链接腐蚀：

  有些人不喜欢这样的事实   Subversion合并其他人的变化   用自己的本地工作副本   更新时自动更改。   以下是如何将这些文件强制转换为   冲突的状态，所以你可以合并   在您方便时手动。

     

在TortoiseSVN-＆gt;设置 - ＆gt; Subversion   配置文件，单击编辑   按钮。更改[helpers]部分   通过添加

diff-cmd = "C:\\false.bat"
diff3-cmd = "C:\\false.bat" 

     

（注意双反斜杠）创建文件   C:\false.bat包含两行

@type %9
@exit 1 

     

这有效地使自动合并失败   每次都迫使文件进入   冲突。

     

好奇type %9的原因   line是diff3-cmd发送的   合并输出到stdout。颠覆   然后采取这个并覆盖你的   具有合并结果的本地文件。   添加此行可避免获取   空本地文件。

Answer 2

由于您的同事使用自动合并令人不舒服，我对不进行自动合并的同事感到不舒服。在我看来，这是错误的心态。当您不接受所有存储库的更改时，您选择取消提交代码，但这样做的方式不会感觉就像取消提交一样。这是一种容易引入和/或重新引入错误的心态。

当您在允许之前查看合并时，您正在考虑将允许哪些更改进入您的代码库，而实际上您正在决定要从代码中删除哪些已提交的代码片段基础。这是一个微妙但重要的区别。

当然需要协调更改，当然可能需要撤消或修改已提交的代码。如果没有接受其他人的提交，就会导致人们撤销提交而不承认你正在做的事情。

Answer 3

也许你可以建议他试试git。 git提供了一个命令“stash”，用于在从存储库进行更新之前保存工作副本的状态。

引自manual page：

中的说明

  

想要录制时使用git stash   当前的工作状态   目录和索引，但想要   回到一个干净的工作目录。

Answer 4

假设你不能说服你的同事改变主意，这个电子邮件主题可能有助于强迫Subversion允许他手动完成所有合并：

http://www.nabble.com/Forcing-conflicts-on-svn-update-to21176148.html#a21176148

Answer 5

我认为这里最好的解决方案可能是利用可用的TortoiseSVN client-side hooks。您可以使用Start-Update或Pre-Update挂钩并在钩子脚本中检查本地工作副本以查看是否存在任何未提交的更改，如果是，则中止更新。

Answer 6

TortoiseSVN允许编辑Subversion配置文件，所以我猜这个选项可以在那里配置。您可以通过Settings-＆gt; General访问它，然后单击subversion组框中“Subversion配置文件”行上的“编辑”。

至于道德问题，从纯粹主义者的角度来看，他可能是正确的，但对我来说似乎更容易手工和容易出错。

Answer 7

也许您可以说服他让svn进行更改，并让他在办理登机手续之前对其进行审核？

我发现命令'svn diff --diff-cmd = kdiff3'对于这个场景非常有用。虽然这是Linux，你的语法会因TortiseSVN而异。

Answer 8

实际上，我认为对合并的轻微不信任可能是一件好事。 在我看来，svn存在一个问题，你无法检查你的更改，然后，一旦它们安全，就合并它们。 但你可以手动完成：

1. Checkout trunk
2. 进行更改并测试
3. 将工作副本分支到临时分支
4. 提交（phew，您的更改是100％纯净且完全安全）
5. 切换到主干
6. 重新整合分支（这是合并步骤，但您的更改在分支中是安全的）
7. 提交
8. 删除分支

它为您的工作流程添加了额外的步骤，但它可能会让您高枕无忧。它还为您提供了与tfs的搁置集近似的等价物。

Answer 9

我曾经非常害怕合并，但我从未见过SVN的自动合并失败的情况。它可能会明显地破坏业务逻辑，因为两个编辑可能在逻辑上冲突而没有物理冲突，但我不认为它会自动合并，除非它是合适的。

如果您没有进行回归测试，那么由于没有对“逻辑合并”进行审查这一事实可能是正确的。但如果你有不错的测试覆盖率，那真是不值得花时间。

我真的不喜欢SVN针对冲突的“合并语法”，但大多数工具似乎都隐藏了它。

Answer 10

在Windows资源管理器中选择有问题的文件，然后 Shift +右键单击该文件，在TortoiseSVN下，您将看到一些新选项，其中包括“Diff with URL” - 选择存储库中文件的URL，然后选择“HEAD revision”。这将显示左侧的当前工作副本（基于非头部修订）和右侧的头部修订。

现在，您可以手动复制从右到左（从头到WC）的更改，手工挑选哪些更改属于哪些更改属于哪些更改。在此之后，SVN仍然认为您的工作副本基于旧版本。所以做一个更新，但这实际上不会改变任何东西（我认为），因为你已经手动完成了所有的更改。然后正常提交。

显然，对于每个文件，这将是非常繁琐的，一个接一个。但如果它只是一个只有一些变化的文件，那么这可能会有效。也许如果它足够乏味，那么这个人就会放弃并信任SVN的内置合并算法。

Answer 11

在这种情况下，教育似乎是唯一真正的答案