Read the section Vendor Branches of the Subversion Redbook (Version Control with Subversion):
http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html
General Vendor Branch Management Procedure
Managing vendor branches generally works like this: first, you create a top-level directory (such as /vendor) to hold the vendor branches. Then you import the third-party code into a subdirectory of that top-level directory. You then copy that subdirectory into your main development branch (e.g., /trunk) at the appropriate location. You always make your local changes in the main development branch. With each new release of the code you are tracking, you bring it into the vendor branch and merge the changes into /trunk, resolving whatever conflicts occur between your local changes and the upstream changes. ... (See the rest of Vendor Branches chapter of the redbook chapter for the specific commands and a full example.)
Basically you check in the vendor code separate from your project, tag the version, and then svn copy it into your project. This will allow you to make your local modifications while still preserving a pointer to the original release version.
The advantage is that when the vendor releases a new version of their product, the redbook delineates how to incorporate the new version into your project so that the same local changes that you had made to the original version are applied to the new version. It is, of course, sound in theory, but may have some gotchas in practice:
But things aren't always that simple, and in fact it is quite common for source files to get moved around between releases of software. This complicates the process of ensuring that our modifications are still valid for the new version of code, and things can quickly degrade into a situation where we have to manually re-create our customizations in the new version.