When working with some open source projects (in my case Joomla and Moodle), I’ve often had to delve into the core code to make some alterations, but the problem is keeping track of these changes so I know which files to update on the production server, as well as which files to keep a special eye on when upgrading to a new version so my changes aren’t overwritten.
The obvious answer is to load the entire codebase into version control, and then you can easily compare revision 0 (the untouched release code) to the current version or working copy to find the changed files, but it seems like a bit of overkill when you’re only changing one or two files and the project has over 5000 files (like Moodle does).
On one end of the spectrum is a version control repository, on the other is using notepad to manually track the changes… is there anything in between?
I’m not sure why you’re resistant to version control; your situation is exactly what version control is designed to handle!
In fact, the case of several small local changes to a large externally-driven codebase makes it even more important to use proper source control. Using a source control system that has a smart differencing and merging engine ensures that simple changes are simple to merge when updating from upstream, and complex changes have a chance of being trackable.
Given the wide availability of high-quality, zero-cost source control systems, there’s really no reason not to use them.