Support merging across files
Right now the samples on the website about splitting up a class are a bit unrealistic since they all include splitting the class up but keeping it all in the same file. In reality, we often move code to different files and still want to merge. SemanticMerge will be revolutionary if it can solve this problem.
Any updates on this?
This is a common way-of-working and SemanticMerge would truly shine here.
Since SCM support will be needed, you can start with Git as the first "non-Plastic" option if only because it's free and already has good bridges to other systems.
Andrew Tatham commented
This is my scenario....
Branch A has class A
I make branch B from branch A
On branch B, I move most/all of the code in Class A into a new base class.
I switch back to branch A. I make a fix on class A.
I switch back to branch B. I want to merge the fix in to branch B
Because most of the code from branch A has been moved to Branch B's base class, I want the fix to be merged into the base class :)
but in reality I get a load of merge conflicts on class A :(
James Woods commented
The cross file merging would be great but for me the language sensitive cross file difference analysis would be the real benefit in that any large scale method refactors could be reduced to a single line saying that method was refactored.
Any progress on this yet? ... I saw the video that mentioned this last year, would like to give it a spin...
I've taken my 3 votes off the feature request: File "branching" to allow new file to track inheritance from previous file.
I've put them on this instead, as I think this is a much better way of handling the use-case of splitting files discussed in the other feature request.
Yes, in the past I voted for the ability to support file copies with history in Plastic - my use case was the splitting up of a single source file into multiple files during refactoring - so I could associate the split files with the original as modified copies. However, I'd much rather see semantic merge support this directly, in which case I probably wouldn't need the history-through-copy tracking any more.
What I had in mind was conceptually concatenating the files (sorted by name) in the before and after changesets into two 'virtual files', then having semantic merge automatically compare the two virtual files - so its code motion would generalise to detecting both file moves / renames as well as code splitting across several files.
In fact we already have the solution in mind and it is pretty doable.
The only caveat is that implementing it with Plastic SCM (our own version control) will be a no-brainer but adding support for others will since we will need them to send us additional information and not only the conflicting files one by one.