views:

50

answers:

1

MolhadoRef is a refactoring-aware SCM tool that is capable of capturing and versioning of the semantics of Java program entities and refactoring operations that were performed on those entities.

Does anyone know of such a system in the .NET universe? (Why is it that .NET always seems to be way behind java with the type of tool support?)

+1  A: 

Does anyone know of such a system in the .NET universe? (Why is it that .NET always seems to be way behind java with the type of tool support?)

First, your question is a little misleading. This isn't a "Java tool", per se. It's a tool that happens to understand Java, but works as an SCM for any blob of text; you just won't get the refactoring support if it's not Java code. So one could could easily ask instead (and perhaps more accurately), "why doesn't MolhadoRef support C#?"

Second, the reason you don't see many tools like this is because this is an academic research project, not a commercial product. It's also a prototype, not a finished work. Notice that the last update was around 2007.

Finally, the design seems awful. They had to design an entirely separate SCM (Molhado) solely for the sake of implementing these ideas, when it sounds like many of them could have been done in the context of an existing SCM. I won't second-guess the researchers since that smacks too much of armchair quarterbacking, but modern SCM tools like git or svn could very easily have third-party plugins that would do exactly the same thing MolhadoRef does, without requiring you to switch to an entirely new SCM ecosystem and wreck your toolchain.

John Feminella
do you know if anyone is working on this system these days?
Ian Ringrose
@Ian: I'm not aware of anything like this. However, I would add that if people can't understand a project's code without a separate tool to explain refactorings, it says something about the complexity of the project.
John Feminella
@John, the problem we are having is mergeing branches that have refactorings in them, the merge tool does not understand the refactorings, so gets lot of "comflit" that need solving by hand. (Yes the code is way to complex with very large classes etc, hence the refactorings!)
Ian Ringrose
@Ian: I would suggest trying smaller commits that are easier to understand. That way you'll have to spend less effort and time evaluating what should be done about each merge conflict. Merge early and often!
John Feminella
@John, yes merge often is a good ideal. I wish we could but at present we have different teams working on each branch (not under my control)
Ian Ringrose
In that case, mandate that merges into your branch be done incrementally and carefully.
John Feminella