The Subversion manual has a section specifically on Vendor Branches.
The basic idea is you import the current release, unmodified, into the repository via a set of folders which track the external changes (just the external changes, not your modifications to it). Something like ".../repos/vendor/(software)/current". Then branch right away into ".../repos/vendor/(software)/(software-version)". As new releases come out, update the "current" directory and create a new branch, such as ".../repos/vendor/(software)/(next-version)". This lets you (and svn) do diffs on the unmodified source to arrive at what changed externally.
For your modifications to the software, branch the "(software-version)" into your own project, something like ".../repos/(my-project)/trunk/(software)". When you upgrade to the next version of the 3rd party source, tell svn to merge the difference between "(software-version)" and "(next-version)" into a working copy of "trunk/(software)". This pulls all external changes into trunk, neatly upgrading the project source. Branch and tag the project as normal.
The Subversion distro includes a Perl script called "svn_load_dirs.pl", which can help when upgrading the "vendor" project. It discovers deleted, added, and renamed files and modifies your working copy of, for example "(current)", as appropriate.