...
- I find it easiest to open up 4 explorer windows in a grid, showing the old base/custom and new base/custom projects, like so:
- Now, for each file in the "new custom" project, use a diff tool like WinMerge to do two comparisons:
- Compare the "old base" version of that file to the "new base" version, to see what changes Kuali has made to the file.
- Compare the "old base" version to the "old custom" version, to see what customizations Tufts has made to the file.
- Then, update the "new custom" version of the file to accommodate both sets of changes.
- In most cases, the Kuali changes and the Tufts changes won't overlap. For these, just merge the new Kuali changes into the custom file. (If there are a lot of Kuali changes, it may be easier to just copy the new Kuali version over into the kc-custom project and re-add the Tufts changes.)
- In cases where the Kuali changes do overlap with the Tufts changes, you'll need to make a judgement call about how to merge the two files. If Kuali is making changes to a feature/function that we specifically overwrote with our own logic, we may want to simply keep our code – though it may still require updates if Kuali is changing classes/functions that are used by our custom code. Conversely, if Kuali is making a major overhaul to a class, it might be worth re-examining our customizations to see if they still make sense to keep.
- Maven pom.xml files are a special case, since these are usually completely re-written for the Tufts custom projects. Usually, all you'll need to do to the pom file is update the version number near the top to match the new Kuali version.
...