Hi all, just in case you didn’t know, we just published a guide explaining how to write parsers for Semantic. Now it is possible to add any language you want :-)
Now that plugin is fairly well tested, so I expect the 164 other voters (at time of writing) to get busy downloading. :-) https://github.com/sageserpent-open/SemanticMergeScalaPlugin
OK, I've produced an almost completely untested alpha plugin over at: https://github.com/sageserpent-open/SemanticMergeScalaPlugin . So if you're really keen to get Scala support in, how about pulling this project and filling out the missing pieces / doing some integration testing?
The crucial point I'm making is simply that if I see a line (or section) of code in an annotated file, I'd like to jump straight to the annotated revision where that line (or section) of code was last changed. What's more, if the change turns out to be irrelevant to whatever I'm looking for, I'd like to be able to repeat this process, jumping back to the previous change for the same line and so on...
Tracking code motion is a very nice bonus on top of this feature request.
That might work if I was using C# in Visual Studio - but I am using Scala in IntelliJ using the plugin and the Plastic GUI in standalone mode.
I'm looking for something that is available in the Plastic GUI. Also, my focus tends to be on lines of code rather than entire methods, so picking up all the history for a given method would result in a lot of noise - but the idea of using Semantic Merge to track the code motion of a line of code via its enclosing method would definitely help.
As a note, it is currently possible to manually note down the changeset from the annotations view, jump to that changeset and re-annotate - but this is fiddly!
I've found another other feature request in User Voice: Support merging across files
This was raised after this one - and I think it would address the use-case better. I'm taking my 3 votes off this feature and putting them on the other.
I've voted for this too: some things to bear in mind:-
1. Let's say the file 'foo.cs' is split via copying by somebody else on a separate branch - so I still see just 'foo.cs' on my branch. If I make commit modifications to it, then if the other person merges in my branch changes, they should get the opportunity to 'multi-merge' my changes made on 'foo.cs' into their 'foo.cs', foo2.cs', 'foo3.cs'.
2. This is a generalization of the idea of merging through file moves.
3. There should be some way of merging a split committed by somebody else into my own workspace with local uncommitted changes, similar to #1.
4. Mercurial also has this functionality. It allows a 'one-off' merge into each copy - once the merge is done though, subsequent changes to the original file are not merged in during later branch merges.
I see the need for this quite a lot at client sites were I work - many developers are afraid to merge changes and will E-mail copies of files to transmit changes between branches being worked on by different people. They then commit the copied file in a new branch as an evil-twin. So when I get round to merging, I inherit lots of evil twin conflicts.
Mercurial allows evil twins to be merged: it effectively performs three-way merge using an empty file as a common base. As there are merge tools that can identify commonality between the two independent sets of changes (and therefore automatically merge them, as they are the result of the original copy via E-mail), this turns out to be quite an effective way of merging in practice.