10 ms·

If someone can come up with an error free merging for all situations, it would be the "killer app" for configuration management. I would especially look forward

If someone can come up with an error free merging for all situations, it would be the "killer app" for configuration management. I would especially look forward to merging for XML files as well.

cpeterso 8y ago
Do any source control systems have filetype-aware merge algorithms? We can do something smarter when merging XML than textual line diffs.
- yitchelle 8y ago
  Totally agree. Could AI or machine learning be used for this type of application? I don't know much about machine learning, but I could imagine that it could be used to learn the programming habits of a development team and, perhaps, use it as a context for determining its merging strategies.
- makapuf 8y ago
  Or any language grammar, in fact.
- jpeloquin 8y ago
  Git can be told to use custom diff and merge drivers for particular file extensions via .gitattributes: https://git-scm.com/docs/gitattributes https://git-scm.com/docs/gitattributes For example, I have used .gitattributes to make git use MS Word to merge docx files, and LabView to merge .vi files. TortoiseGit (for Windows) includes diff/merge driver scripts for use with MS Word files.
- jharger 8y ago
  While not a source control system, the JetBrains IDEs have a very good merge tool that is filetype aware. For example, WebStorm/IntelliJ Ultimate, when merging JavaScript, often has a "magic wand" option that can detect when merge conflicts are actually resolvable if you parse both sides first, and merge the AST. It doesn't always work quite right, but it's good enough that I use it quite often.
- fowl2 8y ago
  Plastic SCM claims to have C#, Java, C and VB.net semantic diff. Looks pretty impressive - sad that it's proprietary! https://www.plasticscm.com/features/semantic-version-control.html https://www.plasticscm.com/features/semantic-version-control...
- WorldMaker 8y ago
  My experiments showed that you can get good character-based diffs from using a syntax highlighting tokenizer. [1] It was faster than a pure character diff algorithm, but the resulting diffs/patches are interoperable, and provided quite reasonably semantic diffs on the examples I tested. Most tokenizers are great too because they tend to operate very well with work-in-progress code or broken/edge-case code (because they are the same sorts of tools we use in our editors). I've not seen someone actually use it for source control, but the core idea is simple enough for the taking. [1] https://github.com/WorldMaker/tokdiff https://github.com/WorldMaker/tokdiff
nradov 8y ago
You're never going to avoid all errors, but with additional tools SVN merging seems no more error prone than Git. I do agree that source code control needs to move beyond lines to deal directly with nodes in a tree structure. That could be XML, JSON, a C++ parsed abstract syntax tree, etc.
- lmitchell 8y ago
  So I've actually thought about this a fair bit recently, since I'm making some changes to C++ code that touch a lot of files in reasonably straightforward ways. The changes should be possible to merge conflict-free in basically 100% of cases, but since so many lines are touched, no VCS merge tool can manage it. Most of my changes are just typenames, so I figured, you could do some sort of AST-based merge to allow those changes to merge with semantic changes to the surrounding code. But this has a lot of problems. Namely - most of the time, when two people change the same line, the changes really do conflict, and someone really does need to manually merge them. In fact, sometimes even when your VCS merges things happily, it still gets them wrong because two changes conflict semantically but don't touch the same lines. So I guess I would say, I think merging is an impossible problem to 'solve', and going to a more granular merge strategy is actually a move in the wrong direction. You could maybe fix my particular case by 'whitelisting' those typename changes, and saying 'these are allowed to merge with anything else', but at that point... the effort required to specify that unambiguously and make it work properly is probably higher than just merging the changes.

If someone can come up with an error free merging for all situations, it would be the "killer app" for configuration management. I would especially look forward to merging for XML files as well.

cpeterso 8y ago

Do any source control systems have filetype-aware merge algorithms? We can do something smarter when merging XML than textual line diffs.

yitchelle 8y ago
Totally agree. Could AI or machine learning be used for this type of application? I don't know much about machine learning, but I could imagine that it could be used to learn the programming habits of a development team and, perhaps, use it as a context for determining its merging strategies.
makapuf 8y ago
Or any language grammar, in fact.
jpeloquin 8y ago
Git can be told to use custom diff and merge drivers for particular file extensions via .gitattributes: https://git-scm.com/docs/gitattributes https://git-scm.com/docs/gitattributes For example, I have used .gitattributes to make git use MS Word to merge docx files, and LabView to merge .vi files. TortoiseGit (for Windows) includes diff/merge driver scripts for use with MS Word files.
jharger 8y ago
While not a source control system, the JetBrains IDEs have a very good merge tool that is filetype aware. For example, WebStorm/IntelliJ Ultimate, when merging JavaScript, often has a "magic wand" option that can detect when merge conflicts are actually resolvable if you parse both sides first, and merge the AST. It doesn't always work quite right, but it's good enough that I use it quite often.
fowl2 8y ago
Plastic SCM claims to have C#, Java, C and VB.net semantic diff. Looks pretty impressive - sad that it's proprietary! https://www.plasticscm.com/features/semantic-version-control.html https://www.plasticscm.com/features/semantic-version-control...
WorldMaker 8y ago
My experiments showed that you can get good character-based diffs from using a syntax highlighting tokenizer. [1] It was faster than a pure character diff algorithm, but the resulting diffs/patches are interoperable, and provided quite reasonably semantic diffs on the examples I tested. Most tokenizers are great too because they tend to operate very well with work-in-progress code or broken/edge-case code (because they are the same sorts of tools we use in our editors). I've not seen someone actually use it for source control, but the core idea is simple enough for the taking. [1] https://github.com/WorldMaker/tokdiff https://github.com/WorldMaker/tokdiff

nradov 8y ago

You're never going to avoid all errors, but with additional tools SVN merging seems no more error prone than Git. I do agree that source code control needs to move beyond lines to deal directly with nodes in a tree structure. That could be XML, JSON, a C++ parsed abstract syntax tree, etc.

lmitchell 8y ago
So I've actually thought about this a fair bit recently, since I'm making some changes to C++ code that touch a lot of files in reasonably straightforward ways. The changes should be possible to merge conflict-free in basically 100% of cases, but since so many lines are touched, no VCS merge tool can manage it. Most of my changes are just typenames, so I figured, you could do some sort of AST-based merge to allow those changes to merge with semantic changes to the surrounding code. But this has a lot of problems. Namely - most of the time, when two people change the same line, the changes really do conflict, and someone really does need to manually merge them. In fact, sometimes even when your VCS merges things happily, it still gets them wrong because two changes conflict semantically but don't touch the same lines. So I guess I would say, I think merging is an impossible problem to 'solve', and going to a more granular merge strategy is actually a move in the wrong direction. You could maybe fix my particular case by 'whitelisting' those typename changes, and saying 'these are allowed to merge with anything else', but at that point... the effort required to specify that unambiguously and make it work properly is probably higher than just merging the changes.