Dirk Rombauts

Picklesdoc

SemanticMerge takes the stress out of merging and lets me merge with confidence.
SemanticMerge has made it easier for me to merge C# code. SemanticMerge helps me by minimizing the amount of code that needs to be verified at one time. That in turns makes a merge less stressful and I feel more confident that I get it right. Some colleagues of my day job used the trial version of SemanticMerge to do one of those awful “pull the changes of the other teams of the last two months” merges. A merge like that used to take several days but it took them only a couple of hours using SemanticMerge.

Tell us a bit about your project and your background.
Pickles is an open source Living Documentation Generator written in .NET. When you specify the expected behavior of software using the technique called Specification By Example, you create a specification that is both an automated test suite and a documentation of the system. Pickles can take that specification and turn it into an html website, a Word document or an Excel sheet. A website or a Word document are more accessible for non-technical people than files in a source control system. Pickles can optionally read the test results from several popular unit testing frameworks like nUnit, MsTest, xUnit, Cucumber and SpecRun to annotate each scenario in the Living Documentation with the result of the last test run.
What is the challenge you are solving for your customers with your project?
The idea of a Living Documentation Generator is not new. The original version is Relish (http://www.relishapp.com). While Relish produces good-looking websites, there are two main drawbacks with their approach. The bigger drawback is thatpeople need to host their Living Documentation in the cloud. Relish offers private repositories for paying accounts, but the Living Documentation is still in the cloud. At my day job I work with customers who are very security-minded and dislike cloud storage intensely.
The smaller drawback is that Relish is Ruby-based: if Relish were to offer an on-premise version, people would be obligated to set up a Ruby server environment. People with a lot of experience with .NET will naturally prefer a .NET implementation.
What challenges were you having to that made you start looking for something like SemanticMerge?
Basically, nobody likes to merge. Our development style encourages a lot of refactorings, we inline methods, we extract methods, we move methods around in a file, … in short the contents of a file will change a lot, which makes merges even more problematic than usual.
What other tools did you try before SemanticMerge? How did they work out?
We obviously use the default merge/diff tools of Visual Studio. We also tried WinDiff and WinMerge, and Beyond Compare. These tools do a decent enough job of highlighting the differences and conflicts, but their chief problem is that the merge/diff is done on file level. If I move a method from the top to the bottom of the file, I will need to do a lot of up-and-down scrolling to find out whether something really changed in the method.
How did you finally find out about SemanticMerge? (how did you discover us) A colleague told me about SemanticMerge.
A colleague told me about SemanticMerge.
How has SemanticMerge been a solution for you? Any specifics?
SemanticMerge limits the scope of the merge/diff to the method instead of the file. If I move a method from the top to the bottom of the file, SemanticMerge will recognize that this method is present in both files, and will simply tell me whether something changed in the method. So I don’t need to scroll up and down anymore, and simply need to compare the two versions of that method.
What kinds of results has SemanticMerge brought you?
SemanticMerge has made it easier for me to merge C# code. SemanticMerge helps me by minimizing the amount of code that needs to be verified at one time. That in turns makes a merge less stressful and I feel more confident that I get it right. Some colleagues of my day job used the trial version of SemanticMerge to do one of those awful “pull the changes of the other teams of the last two months” merges. A merge like that used to take several days but it took them only a couple of hours using SemanticMerge.
That being said, the UI of SemanticMerge is sufficiently different from traditional merge tools that it requires some effort to use it efficiently. I’m doing OK with it, but yet another colleague doesn't feel at home with it.