Skip to content

Latest commit

 

History

History
147 lines (132 loc) · 6.45 KB

resolve.org

File metadata and controls

147 lines (132 loc) · 6.45 KB

Resolve

Plan

  1. Finish collecting conflicts from our JavaScript projects.
  2. Focus on polishing this tool ast-diff for JavaScript first.
  3. Build a (private) Web REST-API for the differencing and merging.
  4. Build in the ability to collect some analytics.
  5. Read about minimum users before we move to the marketplace. (Figure out if maybe we should try the marketplace as another)
  6. Build a web front end with some analytics.

Competitors

There are unused research prototypes and there are very simple commercial tools. There are no tools like this in the GitHub marketplace that returns against searches for “merge” or “diff.”

The most sophisticated commercial tool named “semantic merge” (note: semantic merge has a distinct meaning in the research community and that is not what this tool does). Semantic merge is developed by a version control company (plastic VC). It looks to target MS Windows and doesn’t support JavaScript. I think it is in another section of the market.

https://www.semanticmerge.com

Publications

Automated Merge Conflict Resolution

Potential paper.

Contributions:

  • A novel semantic merge strategy made possible by the increased use of CI and increased programmatic availability of test suites (c.f. semantics [16,17] and hybrid [2,18,19])
  • Empirical results of AST-level differences.
    • How many conflicts may be avoided. (c.f. syntax [9-15])
  • Empirical study of merge conflicts in C/C++ and JavaScript
  • Empirical study of merge conflicts in non-primary language files. Most importantly build and test infrastructure (cf. test see [22,23]). These are necessary when using the test suite as objective function.

Related work

  1. A state-of-the-art survey on software merging
    • Yang [66]
    • Rational Rose TM Visual Differencing tool – UML TM diagrams
  2. Balancing precision and performance in structured merge
  3. A framework for shared applications with a replicated architecture
  4. Pro Git
  5. An algorithm for differential file comparison
  6. A file comparison program
  7. Difference Algorithm and its Variations – Algorithmica, vol. 1
  8. Data Consistency for P2P Collaborative Editing
  9. JDiff: A differencing technique and tool for object-oriented programs
  10. Program integration for languages with procedure calls
  11. Syntactic software merging
  12. Extensible language-aware merging

13. 14. 15.

  1. Software merge: semantics of combining changes to programs
  2. Semantic Diff: A Tool for Summarizing the Effects of Modifications.

18.

  1. Semistructured merge: rethinking merge in revision control systems

20. 21. 22. 23.

Tasks [0/2]

Lookup “state based merging”

Finish the JavaScript experiment using ast-merge

Notes and Ideas

Meetings

Shin Hwei <2019-04-11 Thu>

Top level:

  • Maybe target the ICSE deadline instead
  • Maybe talk at ICSE

Classes of related work

  • state based merging
  • syntactic
  • structured
  • semantic
  • temporal (editor support)

Shin Hwei’s Student

  • using Gumtree to mine edit scripts from Java
  • Using Gin to search combinations of edit scripts
    • random mutations only
    • single file only
  • Looking at what to use beyond test cases
    • Test cases are not sufficient, too easy to pass
    • LOC or complexity maximization (heuristic of keeping everything new)

Compare between source languages?

  • Maybe the languages are too different to be worth comparing
  • How does Java stack up? (More like C or more like JavaScript)
    • Android is more like C, lots of extra stuff, xml files
    • Pure Java is more like JavaScript

Product Council <2019-04-03 Wed>

  • Focus on JavaScript first. It avoids the complication of having to use compilation databases, worry about flags, etc…
  • GitHub’s Market place could be a good place to
    • Get some validation that it is working reliably
    • Build a user community
  • It might be that we could share this with Mozilla (Vineeth has contacts) if we want people to try out the JavaScript.
  • Pay for this under Bug-Injector
  • MVPs
    1. ast-diff (REST Web access with front end.)
    2. ast-merge
    3. github

Synthesis productization meeting <2019-02-15 Fri>

From https://git.grammatech.com/synthesis/meta/wikis/meetings/2019-02-15-productization.

  • Potential customers
    • Github could incorporate our tools as a distinguishing feature. E.g., our automated merge conflict resolution. There is a spectrum here from the Marketplace up to incorporation into an existing dominant Marketplace service all the way up to incorporation into GitHub itself.
    • Development shops. Large development companies are rolling many similar tools themselves. Perhaps they would purchase them from us instead.
  • We should start dogfooding these tools as soon as they’re sufficiently mature.
  • Potential customers (thinking e.g. GitHub here but also applies to development shops) will be facing a “Buy or Build” question. We should have good arguments in this respect… what distinguishes our tools? What is the value we bring?
    • time to market
    • our total investment KLOC
    • monies and expertise which we have applied
  • Need to collect a table of potential show stoppers along the following lines.
    IssueGitHubGitLabOther
    CL support
    compiler
    languages
    our support/backing
    etc…