我是来自Visual Source Safe（VSS）背景的Subversion（SVN）的新手。在VSS中，编辑文件的人员将检出文件，并锁定其他用户通过Visual Studio进行编辑。我知道SVN是一个并发模型，允许多个人在同一个文件上工作，然后将这些更改合并在一起。我的问题是这样的：如何避免Subversion中的复杂合并？
什么是避免用户编辑同一文件（写成吨的代码），要么面临自己的改变或一个复杂的合并书写更糟糕的一吨的代码，最好的方法只发现该文件被另一个用户锁定？
有没有办法来通知检索文件时，它是当前正由另一用户编辑或正在被其他用户锁定用户？
其他信息：
使用VisualSVN服务器为SVN服务器。
使用TortoiseSVN和AnkhSVN客户端。
我也是以前的Visual Source Safe用户。在我意识到这不是一个技术问题，而是一个人的问题之前，合并曾经让我疯狂。在使用VSS时，大多数开发人员在必须签入代码之前尽可能完成尽可能多的工作。这种行为是造成复杂合并的原因。
以下是减轻这种几件事情：
这些事情非常有帮助，尤其是当我工作的团队不断变得越来越大时。从VSS复制锁定行为是一个非常糟糕的主意，并且会导致更多问题。只需拥抱新的工作流程。
如果你仍然想使用的工具，那么我建议你看看SVNMonitor。
感谢您推荐SVNMonitor。 – Achilles 2009-11-12 16:26:29
你错过了一件重要的事情，使分支一起工作的喜悦。经常更新...树干变化人们已经登记到您的分支机构。和你在第一点中所说的一样。对你的分支做同样的事情，不应该有任何不同的对待。如果您经常更新您的分支，并且人们每天都会检查一下主干，那么最终不会有任何合并地狱，因为您的分支中的代码几乎是最新的或接近最新的干什么，因为你宗教上更新你的分支一直！每日小小的痛苦让生活变得轻松 – PositiveGuy 2012-02-10 05:16:07
我想建议采取不同的方法来使用颠覆。
采用这种方法，合并通常是罕见且自动发生。在冲突的情况下，这些往往较小。
首先，它可能是明智的，避免写“成吨的代码”没有检查的文件，如果可能的话。如果你有一个很好的单元测试套件（如果没有，为什么不呢？），那么只要你在绿色栏上签入，频繁的提交是最好的。
然后，如果确实需要花费很长时间的更改，则定期执行svn update以尽可能保持与主干同步。 Subversion在合并时相当可观（与VSS相比），并能很好地处理大部分内容。
任何它无法处理的东西，它将进入冲突状态，让你解决与你选择的合并工具的冲突（我建议WinMerge这是它的王牌）。
SVN是一个并行模型，允许多个人对同一文件进行操作以后的修改合并到一起。
我认为这更多的是在同一个项目是由一堆独立的文件或多或少的工作。处理同一个文件并合并结果肯定是可能，并且确实会偶尔发生，但绝对不是默认/所需的操作模式。所以：
我在之前的地方从基于锁的系统到SVN的过程中遇到了一些问题。
在SVN中尝试并复制锁定编辑 - 解锁行为并不是一个好主意，因为它的设计方式不需要这样工作。 SVN使用的合并算法相当不错，而且我只遇到了一些需要在合并过程中手动干预的情况。令人惊讶的是，在同一个文件上工作的两个人实际上会碰到同一条线，而后者往往是唯一需要手动干预的时间。
SVN确实是设计用于您从干线或当前分支经常更新的环境中。如果你必须做更长期的工作或者改变文件中大量代码的工作，那么最好使用分支来完成工作并合并它。是的，你必须通过一些合并时不时的疼痛，但它比不用这种方式设计的系统的疼痛要少得多。
如果您尝试使用SVN而不是“本机SVN”，而是使用不同名称的VSS，这将是痛苦的，它不值得冒险。为了适应新的范例，与旧的“只有一个用户在任何给定时间编辑给定文件”例程相比，您会惊讶地发现以这种方式工作的更好。
简短的回答：
稍长的答案：
如果不止一个开发者在同一个文件“成吨的变化”，事情是腥要么与方式的开发工作，或与方式功能分布在不同的文件中。我一直在与CVS和SVN以不同规模的团队合作，并且在合并成为真正的问题时，极少有情况。 （这通常是像串，日志，错误处理等需要改变几乎所有的代码基本服务的变化。这种情况下，需要一些人的互动，并计划顺利进行。）
我同意其他人一样，在尽可能在检查尽早并经常（但并不总是可能）。如果你正在做一些复杂的，新的它可以在一个分支来实现 - 应用同样的规则，提交尽早并经常与地方保持你的分支为最新从起始码为实用。
在我们大部分人的经历往往不会在同一个文件或至少文件的同一部分工作在同一时间（VSS你不能所以你的工作模式可能已经支持你在这）。
还有一个关键问题 - 确保每个人都使用相同的规则来使用制表符和间距，进行布局和格式化，无论如何，这是一个很好的做法，但是一致性越高，您越不可能找到“不存在的代码文件之间的差异“。
另外，我建议你看看持续集成，即有一个构建服务器，这提供了相当大的好处，你的承诺代码将建立在“干净”的环境中，如果你有适当的测试，即使在复杂的合并过程之后，它也会给你更大的信心，即它仍然有效。
我们使用TeamCity我们发现这是极好的 - 但也有其他人。
虽然SVN有一个锁命令，但使用SVN的最常见方式是使用乐观的锁定方法。
这意味着你和我可以编辑同一文件，并不太担心它（大多数时候我们不会因为我们想对我们的项目不同部分的工作时间）。如果我第一次提交对文件的更改，那么提交尝试将失败。那时SVN会通知你。
然后，您将必须运行“更新”命令，将（最有可能）会自动与您当地的更改，然后下次提交的尝试将通过合并我提交的修改。
为了避免陷入麻烦，这种乐观的办法：为别人的建议，承诺往往在一次不要犯太多了！
你可能想使用旧的VSS风格锁定模型中的唯一时间是要版本的二进制文件（MS-Word文档等），但SVN无法自动合并来自多个来源的变化。
谢谢大家的所有建议，并设置我直。 – Achilles 2009-11-12 16:20:14
一年来不及，但我真的不得不推荐阅读SVN手册。它是以一种轻松，实用的方式编写的，并且像一个广泛的SO答案一样阅读。 – 2010-09-16 11:20:35