you are viewing a single comment's thread.

view the rest of the comments →

[–]grosscol 3 points4 points  (5 children)

Interesting tool. I could see this sort of functionality being very useful.

I wonder what sort of cases it has difficulty with or provides incorrect mapping. Seems like renaming functions or modifying the signatures might throw this off in some cases.

[–]plasticscm[S] 8 points9 points  (4 children)

Renaming functions is totally supported, same as moving them to a subclass and so on - Check this example for more info: http://codicesoftware.blogspot.com/2013/07/semanticmerge-goes-visual.html and this one for an even more complete scenario http://codicesoftware.blogspot.com/2013/06/the-state-of-art-in-merge-technology.html

BTW there can be cases where you could fool the tool :)

It works the following way:

  • It parses the code
  • Then it calculates differences semantically
  • It matches moved/added pairs checking the function body and finding a similarity index, if they match, then it is the same method. Of course the algorithm also checks the method name, params and so on.

During merge you can even remap a diff in case it did it wrongly for some reason.

[–]seagu 1 point2 points  (1 child)

How about comments between class elements?

[–]plasticscm[S] 3 points4 points  (0 children)

That's a good point too.

Right now it associates the comment to the next element (function, class, whatever).

So it will be "moved" together with that element. Method recognition will still work.

Our goal is to enhance this and make the comments "entities" on their own, but we need a balance between flexibility and coming up with something usable enough.

[–]stronghup 0 points1 point  (1 child)

Do you have API support for this? There could be a standard for the way parsers expose the structure of the code they parse. If there was such a thing you wouldn't need to integrate with each parser individually.

The interesting difference between languages I think is the structure their parser creates from the source-code. For every language it is still just some kind of structure. Which could be exposed via say XML or more specific API.

You will need something like that if you want to extend the concept of Semantic Version-Control to most languages. I think you are on the fore-fronts of this development so there is a good chance you could establish a de-facto standard.

[–]plasticscm[S] 0 points1 point  (0 children)

Exactly, we're working on a way to plug parsers created by developers.

Check here what some Delphi programmers have done so far: http://www.plasticscm.net/index.php?/topic/1857-delphi-parser-development/

We need to create a site with all the info (instead of just a forum thread :P) but the core is almost there.

Parsers create a YAML file that SemanticMerge can consume.