FC (Windows 文件比较)的更好(?)结果?

Better(?) results from FC (Windows File Compare)?

提问人:Maury Markowitz 提问时间:11/13/2023 更新时间:11/14/2023 访问量:34

问:

FC 菜鸟在这里。我有两个 VB.net 文件,旧的.vb和新的.vb。前者有 33997 行,后者有 34956 行。区别在于:

  1. 将一个小型实用程序方法从第 15k 行周围的先前位置移动到顶部的新模块
  2. 在正文中添加了三个新方法,所有方法都位于第 7500 行周围的一个块中
  3. 另外两个方法被添加到第 12000 行周围的单个块中
  4. 在接近末尾时,在第 28000 行附近添加了一个方法
  5. 一些非常小的更改,例如 WS 和注释中的拼写,所有单行编辑

客户有一个基于 Excel 工作流的报告系统,并要求在 Excel 中记录差异。我首先将文件并排复制到工作表中,然后打算为它们着色以指示更改,并在需要的地方插入空行以使代码再次对齐。对于差异列表,我打算使用 FC。

为了测试,我在 Notepad++ 的比较工具中手动运行了差异,该工具生成了大约十几个更改的列表,这些更改与我想要的完全一样。非常好!

所以后来我这样做了:

FC /a /n /w /lb 50000 c:\old.vb c:\new.vb > c:\temp\changes.txt

这将生成包含 257 项更改的列表。只有第一项(移动的例程)被列为单个块。其余的都是片段,其中 FC 在文件中完全不相关的部分排列了类似的代码行。

例如,在新文件中,我在名为 ReportManagementFees 的正上方插入了一个名为 ReportExpenseImport 的 25 行方法。这是它报告的差异:

这是第二个差异,我在现有方法上方插入了一个新方法:

***** C:\old.vb
 7480:      End Sub
 7481:  #If True Then
 7482:      '----------------------------------------------------------------------------------
 7483:      Friend Sub ReportManagementFees(Props As List(Of Property))
 7484:          '
 7485:          'WRITES A REPORT OF WHERE THE MANAGEMENT FEES COME FROM
 7486:          Dim DbF As DBFactory
 7487:          Dim DS As RecordSet
 7488:          Dim SQL As String
 7489:          Dim WS As WorkSheet
***** C:\NEW.VB
 7497:      End Sub
 7498:      ''----------------------------------------------------------------------------------
 7499:      'Public Sub ReportMissingExpenses(RptId As Integer, Props As List(Of Property))
 7500:      '    '
 7501:      '    'WRITES A REPORT COMPARING THE ACCOUNTS TO THE
 7502:      '    'EXPENSES
 7503:      '    Dim DbA As DBFactory
 7504:      '    Dim DS As RecordSet
 7505:      '    Dim WS As WorkSheet
 7506:      '    Dim R As Integer
 7507:      '    Dim SQL As String

ReportMissingExpenses 是文件中的下一个方法,位于 ReportManagementFees 之后。因此,它将一个旧例程与另一个旧例程相匹配,并且实际插入的块不会在我能看到的任何地方列出。它似乎在文件的小子集上匹配,只要有几行长的类似代码?我的感觉是:

  1. 我没有正确设置命令行开关,也许是 /lb?我在这里尝试了许多不同的值 - 太小了,我得到了重新同步,比较完全失败,任何超过该限制(大约 1000 行)的值,我得到了上面的结果。我在这个特定的运行中使用了 50k,因为它比任何一个文件都大,但即使是 250000 也不会改变结果。

  2. 我误解了结果。FC 输出中的每个“中断”都有一个起点和终点线,如上所述,它们似乎未对齐。但也许我根本就不明白它在说什么?但在这种情况下,为什么它会列出 ~250 个更改,而实际上只添加了几个块?

我怀疑 (1) 是问题所在,但文档相当稀疏。SO 上关于该主题的线程很少,所有第 3 方网站都只是抓取 MS。

或者,如果有人熟悉更好的命令行工具,我很乐意尝试。

vb.net fc

评论

0赞 Andrew Morton 11/14/2023
如果你使用版本控制系统,例如 git,你可以用它来向你展示差异。该程序将受到版本控制。我假设您知道拥有如此多行的文件是不好的做法。
2赞 Andrew Mortimer 11/14/2023
看看 WinMerge 如果你在版本控制系统中没有这个,它本身提供了一个比较。
0赞 Maury Markowitz 11/14/2023
“看看 WinMerge” - WinMerge 产生了正确的输出(我假设它与 Notepad++ 是相同的算法)并立即这样做。不过我不熟悉这个工具,有没有办法输出生成的分屏,将差异显示为单个文件?我找不到任何类型的保存或导出,除了将原始文件保存回去的保存或导出。

答:

0赞 Maury Markowitz 11/14/2023 #1

WinMerge 几乎是解决方案。

WinMerge 迅速对这两个文件进行了完美的比较。我打开了这两个文件并将“合并报告”保存到一个临时文件中,然后在 VBA 中将其作为 String() 打开。每个数组条目都表示一个可能的差异,但您必须过滤掉许多信息行并查找以数字开头的“命令行”。就我而言,合并文件中有 1018 行,但只有 15 个命令行。

命令行的格式为 line1[,line2][a|d|c]line1[,line2]。例如,如果有新行添加到较新的文件中,您将得到类似“1234a2345,3456”的内容。这意味着 3456-2345 = 1111 已添加到文件 2,因此要使两个文件再次对齐,请在文件 1 的第 1234 行下方插入 1111 单元格。

完成所有插入需要几秒钟,但一旦完成,我最终在 Excel 中重新创建了原始合并显示。

几乎是我还没有弄清楚使用命令行保存合并文件。文档相当有限,许多条目被标记为“待定”。但是,由于内部引擎似乎是 GNU,并且合并报告的格式在现代实现中是相同的,因此相同的 VBA 代码将适用于任何现代差异(似乎 FC 不是)。

评论

0赞 Maury Markowitz 11/17/2023
“真正”的解决方案是下载适用于 Windows 的 diffutils。这是 WinMerge 中的底层代码,并且有一个完整的 CLI(当然),它允许您捕获输出并解析它,而不会产生歧义。