如何避免颠覆中的复杂合并?

我也是前视觉源代码安全用户。在我意识到这不是技术问题,而是人的问题之前,合并常常让我发疯。在使用VSS时,大多数开发人员在必须签入代码之前,都会尽可能多地完成工作。这种行为导致了复杂的合并。

以下是一些缓解这一问题的方法:

• 开始前始终更新工作副本
• 经常登记。这将使代码更改变小,从而更容易自动合并
• 不要取消选中工作代码
• 如果更改需要几天或更长时间,开发人员应该创建自己的分支

这些都起到了很大的作用,尤其是当我所在的团队不断壮大的时候。从VSS复制锁行为是一个非常糟糕的主意,并且会导致更多的问题。接受新的工作流程。

如果你还想使用工具,那么我建议你看看 SVNMonitor .

我建议采取不同的方法来使用颠覆。

• 你应该经常得到更新。
• 你也应该早点和经常登记。

使用这种方法,合并通常很少发生,并且是自动发生的。在冲突的情况下,这些通常较小。

我以前在一个地方遇到过几个点,我们从一个基于锁的系统转到了SVN。

尝试在SVN中复制lock-edit-unlock行为并不是一个好主意,因为它是以一种您不需要这样工作的方式设计的。SVN使用的合并算法非常好,我只遇到过一些需要在合并期间进行手动干预的情况。令人惊讶的是,在同一个文件上工作的两个人实际上会碰到同一行,后者通常是唯一需要手动干预的时候。

SVN实际上是为在经常从主干或当前分支进行更新的环境中使用而设计的。如果你必须做一些长期的工作,或者是改变文件中大量代码的工作,你最好使用一个分支来完成这些工作,并将其重新合并。是的,你会不时地经历一些合并的痛苦,但是比起一个没有设计成那样工作的系统,这种痛苦要少得多。

如果您试图使用SVN,而不是作为“本机SVN”,而是作为具有不同名称的VSS,这将是很痛苦的,不值得麻烦。熟悉新的模式,你会惊讶地发现,与“在任何给定时间只有一个用户编辑一个给定文件”的老程序相比,以这种方式工作的更好。

首先,如果可能的话,最好避免在不签入文件的情况下编写大量的代码。如果您有一个好的单元测试套件(如果没有,为什么不呢?:),那么,只要您在绿条上签入,频繁提交是最好的。

那么,如果你确实有需要花费很长时间的变化,那么值得做一个 svn update 定期与后备箱保持同步。Subversion在合并(与VSS相比)方面相当受人尊敬,它可以很好地处理大多数内容。

它无法处理的任何事情都将进入冲突状态,让您使用自己选择的合并工具来解决冲突(我建议 WinMerge 为此,这是王牌)。

唯一一次您可能想要使用旧的VSS样式锁定模型的是您想要版本的二进制文件(MS Word文档等),但是SVN不能自动合并来自多个源的更改。

没问题。使用Tortoise SVN,执行此操作…

1. 在Windows资源管理器中,右键单击 文件。
2. 选择“Tortoise SVN”然后选择“GeT” 锁……
3. 在“锁定文件”对话框中,填充 在你的理由锁。
4. 单击确定。

尽管SVN有一个 锁 命令,使用SVN最常见的方法涉及到锁的乐观方法。

这意味着你和我可以编辑同一个文件,而不必担心太多(大多数时候我们不会这样做,因为我们要处理项目的不同部分)。如果我是第一个提交对文件的更改,那么您的提交尝试将失败。这时SVN会通知您。

然后,您将必须运行“更新”命令,这将(很可能)自动将我提交的更改与您的本地更改合并,然后您的下一次提交尝试将继续进行。

为了避免这种乐观的做法带来麻烦:正如其他人所建议的,经常承诺,不要一次承诺太多!

SVN是一个并发模型,允许多个人处理同一个文件,然后将更改合并到一起。

我觉得这更多的是在做同样的事情 项目 它由一堆或多或少的独立文件组成。处理同一个文件并合并结果肯定是 可能的 并且偶尔也会发生,但这绝对不是默认/期望的操作模式。所以:

• 经常更新。
• 经常犯错误。
• 避免使用大型类/文件(1000行太多)。这也有其他好处:—)

我想花点时间学习一下“签到舞”

这里有一个 dime cast 关于它。

网上也有很多关于这个以及如何减轻痛苦的文章。

简短回答:

1. 经常更新。早点登记,经常登记。如果您的工作时间更长(超过一到两天),请考虑创建一个功能分支。
2. 不。

更长的回答:

如果不止一个开发人员在同一个文件上做了“大量的更改”,那么无论是您的开发人员的工作方式,还是特性在不同文件上的分布方式,都有一些可疑之处。我已经在不同规模和时间的团队中与cvs和svn一起工作了。当合并成为一个真正的问题时,很少有情况发生。(这些通常是基本服务的更改,如字符串、日志记录、错误处理等,需要更改几乎所有代码。这种情况需要一些人与人之间的互动和计划才能顺利进行。)

我同意其他人的意见,尽可能早点和经常登记(不是 总是 可能的)。如果你在做一些复杂和新的事情,它可以在一个分支上完成——同样的规则也适用,尽早并且经常提交,并且在哪里让你的分支保持最新,尽可能地从头部获取代码。

根据我们的经验,大多数情况下,人们往往不会同时处理同一个文件或至少是文件的同一部分(在VSS中, 不能 所以您的工作模式可能已经在这方面支持您了)。

还有一件关键的事情——确保每个人在使用制表符/间距、布局和格式时都使用相同的规则,这是一个很好的实践,但是越一致,就越不可能发现不存在的代码文件之间的“差异”。

此外,我建议您关注持续集成,即拥有一个构建服务器,这对于您承诺的代码将在一个“干净”的环境中构建具有相当大的好处,并且,如果您适当地配备了测试,那么即使在一个复杂的合并过程之后,它仍然可以工作,这也会给您带来更多的信心。

我们使用 TeamCity 我们发现这是很好的-但还有其他的。