General advice on patch-updating old releases
The recommended solution is to upgrade to the latest release in your series. Between 4.6.10 release date in Nov 2015 and time of this question, there have been multiple CiviCRM security releases. See https://civicrm.org/advisory for the full list.
As you're finding, patch updates are labour intensive, which is why we recommend upgrading to a supported release.
As the codebase to be patched (the 4.6.10 site) and the codebase the patch was made for (4.6.24) diverge, the odds of the patch applying cleanly are reduced. This can be an uncomfortable situation.
How do people get here?
The need to backport fixes may indicate -
- A site is reluctant to upgrade because the CiviCRM codebase has been directly modified. Instead of customising CiviCRM directly by modifying the core code, we recommend customising via extensions, overrides, and the other interfaces CiviCRM provides for customisation..
- A site is reluctant to upgrade because the upgrade might bring unexpected changes. This may be addressed through testing (automated or manual). Currently the CiviCRM community is discussing ways to make upgrading a more predictable process for sites.
- A site may have opted to skip upgrades due to limited budget or resources, and now wants to track "bare minimal" updates for security only. This tends to increase the cost of maintenance over time.
Those are the most common underlying reasons sites find themselves having to backport fixes. These reasons may be valid, or they also might not apply to your instance at all, but I'm adding this additional answer in the hope that it helps some sites out there avoid the situation in question.