The guys talk to Pablo Santos about Semantic Merge, a merge tool that understands your code.
Download / Listen: Herding Code 183: Semantic Merge with Pablo Santos
Show Notes:
- Intro
- (00:18) Semantic Merge is a diff tool with a semantic understanding of your code.
- Language support
- (01:01) Jon asks about what languages Semantic Merge supports. It currently supports C#, Visual Basic.NET and Java, and they’re currently working on adding support for C, then C++.
- (02:00) Jon noticed that they’re using Roslyn and asks about that. Pablo says that it worked really well, handling the parsing to allow them to focus on the important things like diff calculation and semantic merge calculation
- (03:02) Jon asks about support for JavaScript. Pablo says it’s still under development and there’s a lot of demand for it. Since JavaScript isn’t so tightly structured, they’re still working on figuring out how to come up with something really useful there.
- (04:08) Jon asks about how they handle parsing outside of Roslyn and .NET. Pablo lists the different parsers they use for different languages. They’ve opened up the way that languages plug in, which allowed for a community contributed Delphi parser.
- (5:33 Scott K. asks about support for Typescript, since it’s more strongly typed. Pablo says that’ll be easier, but they’re working through the language support list in order of demand.
- What kind of semantics can Semantic Merge understand?
- (06:28) K. Scott talks about what Semantic Merge does at a high level and asks about the different refactorings Semantic Merge can and can’t understand. Pablo explains a common scenario in which you’d be afraid to refactor code while adding or changing functionality if you know someone else is also working on it. Semantic Merge understands the refactorings so it’s easy to merge the actual changes. What Semantic Merge currently doesn’t handle is multi-file semantic merges, e.g. with code being refactored into another file. They’ve got a working prototype for that, but it’s harder to plug into different source control systems since they handle multi-file merges differently.
- (08:52) Pablo points out that, while it’s called Semantic Merge, the diff functionality is really useful on its own.
- The importance of graphical representation of merge issues
- (09:17) Jon talks about how good the graphical representation is – both really easy to read and just generally nice looking. Pablo says they’ve put a lot of work into that and explains why they’ve designed it as they have.
- (10:41) Scott K. says that developers are often stuck in a textual viewpoint for diff and merge, but a good graphical representation can be really useful. Pablo says that we’ve seen a recent revolution in source control tools, but we’re still using tools and technologies from twenty years ago. Jon says that the older ways of displaying diff and merge results with plus and minus lines was based on working with the old source control systems and mostly doing two-way merges.
- (13:25) Pablo says it’s something that you really miss when it’s not there – big merges with lots of files look scary, but when you see that the actual changes are minimal it’s not such a big deal. Scott K. mentions a joke he saw on twitter about how a ten line code review finds ten issues, but a thousand line review passes easily.
- (15:17) Jon asks how Semantic Merge has changed the way their team develops code, for instance by making them more ready to refactor code. Pablo gives an example with working on a year-old branch in which traditional diff gave him tons of merge conflicts but Semantic Merge only gave him one.
- (17:19) Jon noticed that many of the samples were able to automatically merge everything and asks how Semantic Merge detects merge conflicts. Pablo explains how Semantic Merge not only is able to detect when changes don’t cause conflicts, but can also detect merge conflicts that other tools won’t find.
- Version control integration
- (19:36) Jon asks about which version control systems Semantic Merge integrates with. Pablo lists Git, Mercurial, TFS, Perforce, Sourcetree and Subversion and says that it’ll plug into just about anything because just about all version control systems use common conventions for diff / merge tool integration.
- Platform support
- (20:51) Jon asks about their recent Linux support and asks if that’s done using Xamarin and Mono. They use Mono for common backend code, but wrote native front-end code for Linux using Gtk#. They’re currently working on an OSX version using MonoMac, which gives it a true native front-end with a standard Mac look and feel.
- Pricing model and free licenses
- (22:52) Jon asks about the pricing model. There’s a 15 day free trial and a monthly subscription for $4/month. They wanted to experiment with pricing to make it so inexpensive that pricing wasn’t an issue. Jon asks if the subscription checking is complex. Pablo says it give you a lot of leeway so it won’t block you if you’re coding on a plane or something. They don’t obsess over security since it’s such an inexpensive application to begin with.
- (25:36) Jon asks about their free licenses for open source developers. Pablo says they use Mono extensively and have been offering open source licenses for Plastic SCM for a while. Pablo mentions some of the open source projects using Semantic Merge, including F-Spot and a lot of other Mono projects.
- Semantic based insights
- (26:57) Jon asks they could use their information about semantic changes to source code over time to offer other insights to developers. Pablo says that this is something they’ve been doing with Plastic SCM with features like semantic method history, so you can track changes to a method over time across renames, refactoring to other files, etc. They also can offer richer metrics, so you don’t just see lines of code changed but can understand methods changed, refactorings, etc. Their goal for a long time has been to transform version control from a delivery mechanism to a productivity tool for developers.
- Plastic SCM
- (29:04) Jon asks how Plastic SCM compares to other version control systems. Pablo recommends going to PlasticSCM.com and look at the branch explorer. It’s as powerful as Git but very easy to use. It’s fully decentralized. It’s very graphical, and you can do almost everything from the branch explorer. It integrates well with enterprise security with support for things like ACL’s. It (of course) offers support for a lot advanced merge scenarios. It’s been under development since 2005, they’re in version 5 right now. It’s free for every team under 15 developers.
- (31:25) Jon asks if there’s a way to test-drive Plastic SCM against an existing Git repository. Pablo explains how to do that without changing version control systems, since Plastic SCM can natively use the Git API.
- (34:25) K. Scot asks about an old blog post about a small Windows Git application client; Pablo says that’s no longer required as it’s built into Plastic SCM.
- Wrap up
- (34:55) Jon asks about where listeners can find out more about Semantic Merge and Plastic SCM.
- (35:50) Jon mentions that he really likes the team page on the Plastic SCM site – all the faces follow the mouse cursor as you move it around. He’s easily amused.
Show Links: