...
- 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.