- Finish collecting conflicts from our JavaScript projects.
- Focus on polishing this tool
ast-diff
for JavaScript first. - Build a (private) Web REST-API for the differencing and merging.
- Build in the ability to collect some analytics.
- Read about minimum users before we move to the marketplace. (Figure out if maybe we should try the marketplace as another)
- Build a web front end with some analytics.
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.
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.
- A state-of-the-art survey on software merging
- Yang [66]
- Rational Rose TM Visual Differencing tool – UML TM diagrams
- Balancing precision and performance in structured merge
- A framework for shared applications with a replicated architecture
- Pro Git
- An algorithm for differential file comparison
- A file comparison program
- Difference Algorithm and its Variations – Algorithmica, vol. 1
- Data Consistency for P2P Collaborative Editing
- JDiff: A differencing technique and tool for object-oriented programs
- Program integration for languages with procedure calls
- Syntactic software merging
- Extensible language-aware merging
13. 14. 15.
- Software merge: semantics of combining changes to programs
- Semantic Diff: A Tool for Summarizing the Effects of Modifications.
18.
20. 21. 22. 23.
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
- 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
- ast-diff (REST Web access with front end.)
- ast-merge
- github
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.
Issue GitHub GitLab Other CL support compiler languages our support/backing etc…