【问题标题】:Are there any merge tools for source control that understand code?是否有任何可以理解代码的源代码控制合并工具?
【发布时间】:2010-10-22 14:19:38
【问题描述】:

我最近一直在处理大型代码库、重构和总体改进设计以增加覆盖率。此外,在相当多的文件中,我删除了多余的 using 语句、移动了方法以使相似的功能靠近在一起、添加了区域等,但实际上并没有改变文件中代码的功能。

与此同时,团队其他地方的其他开发人员正在修复错误并更改代码行。显然,在合并时这可能是一个问题,因为行号不再匹配并且方法可能已经移动。

现在,我了解了一般规则,即在源代码控制的环境中,移动方法可能是一件危险的事情,我们认为收益大于成本。但是我不明白为什么会这样。

假设我的初始文件是一个简单的计算器:

public class Calculator
{
    public int Subtract(int a, int b)
    {
        return a + b;
    }

    public int Add(int a, int b)
    {
        return a + b;
    }
}

我决定让这些方法按字母顺序排列:

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }

    public int Subtract(int a, int b)
    {
        return a + b;
    }        
}

而另一位开发人员修复了减法中的错误

public class Calculator
{
    public int Subtract(int a, int b)
    {
        return a - b;
    }

    public int Add(int a, int b)
    {
        return a + b;
    }
}

标准的合并工具可能需要您手动合并这两个文件,但了解代码的功能的工具可以轻松协调这两个更改。这同样适用于删除或添加其他方法、cmets、区域或 using 语句。

所以,(终于!)提出这个问题:是否有任何合并工具可以智能地理解代码的功能,并且可以在没有任何人工干预的情况下合并上面的两个文件?如果不是,为什么不呢?是否有任何复杂性使这个问题成为一个无法解决的问题(当然理解它并不像我暗示的那么简单 - 但由于某种我看不到的原因是不可能的吗?)

我在我的源代码中使用了 C#,并且很喜欢可以使用它的东西,但是我很感兴趣这是否存在于编程世界的任何地方......


我已经非常担心这个问题的长度,但编辑添加了我期望智能源系统如何工作:

当初始计算器文件被检查时,系统会解析文件并创建类的层次结构:

File: Calculator.cs
|
|--Class[0]: Calculator
    |
    |--Method[0]: Subtract
         |
         |--Line[0]: return a + b;
    |
    |--Method[1]: Add
         |
         |--Line[0]: return a +b;

(大括号等有多余的行...)

当我签入我的代码(使方法按字母顺序排列)时,它会更新上面的层次结构,以便 Subtract 变为 Method[1] 而 Add 变为 Method[0]。

第二个开发人员签入了他的代码(显然源代码控制系统知道它是基于原始代码的)并注意到第一行的减法更改。现在,与其在整个文件中逐行查找该行号,它知道它可以找到一个 Calculator.cs/Calculator/Subtract/0 并且该方法已更改位置的事实并不重要,它仍然可以使合并工作。

【问题讨论】:

  • “自动”对账的结果应该是什么?问题不在于理解语言,而在于理解程序员的意图——这需要心灵感应!
  • 我原以为理解代码功能并可以将其与布局分开的系统会看到第一个更改是纯粹的布局,因此将其应用于文件的布局和第二个更改是纯粹的函数,因此将更改应用于发生函数更改的方法,无论该方法现在可能是什么。
  • 我怀疑这样的野兽不存在,但我很想看到其他答案。我有一种感觉,这样的系统将与 AI 接壤,并将导致 SkyNET VCS。 ;)
  • @Neil:这样的合并工具会认识到:1)方法声明的顺序已经改变,2)其中一个方法的主体已经改变。所以结果将是该工具将重新排序方法并应用方法主体的更改。
  • @martin - 但为什么它应该更喜欢第一个布局而不是第二个(反之亦然)?

标签: version-control merge


【解决方案1】:

我们使用 Plastic SCM 的方法还远未“完成”,但它已经发布,可以在这种情况下提供帮助。看看Xmerge。当然,我们非常欢迎您提供反馈,并会授予一些免费许可证;-)

【讨论】:

  • 看起来不错,但显然不是我希望的 100% 的功能(还)。合并工具是否单独提供?不幸的是,我没有能力在我工作的地方组织一个完整的 SCM 系统更改,但是 XMerge 功能的桌面版本可能非常方便。
  • 通常不会,但请在我们的支持电子邮件中给我们留言(支持在 codicesoftware.com),我们会讨论它
  • 还要检查一下:codicesoftware.blogspot.com/2010/07/…,这是我们新的 Xmerge,具有更好的重构支持。希望你喜欢!
【解决方案2】:

我认为Source Code in Database 是您问题的一个潜在答案。一般的想法是您不版本文件,您版本代码块。版本控制系统了解代码 DOM,并允许您查询代码 DOM,以检查函数、类、您有什么,以进行编辑、编译等。

由于方法的顺序不一定重要,因此它们不会以任何顺序存储在数据库中。当您查看课程时,您可以指定您最喜欢的顺序(字母、公共/受保护/私有等)。唯一重要的更改是您将+ 切换为- 的位置。您不会因为重新排序方法而发生冲突。

不幸的是,SCID 还很年轻,而且没有多少工具可以用于它。然而,在查看和编辑代码的方式上,这是一个相当有趣的演变。

编辑: Here's another reference for SCID

【讨论】:

  • 感谢您的链接,当我在上面的编辑中写“有额外的行用于大括号等...”时,看起来是正确的想法和有趣的是,我实际上认为“拧大括号,让源代码控制系统添加它们并结束标签/空间战争”,但不想混淆问题。很高兴看到我们正朝着那个方向前进,即使我们还没有完全到达那里。
猜你喜欢
  • 1970-01-01
  • 2012-01-05
  • 1970-01-01
  • 2015-06-10
  • 2012-05-26
  • 2019-02-18
  • 1970-01-01
  • 1970-01-01
  • 2013-05-27
相关资源
最近更新 更多