a couple of good-to-know points about SVN versioning;
In an SVN repo, the 'revision' is a discrete version of the software. But; the revision _number_ is _not_ an indication of sequential functional increment.
Revisions are based on the revision before it, but that does not have to be the one with the revision _number_ before it.
The revision number counter is global to the repo, hence it is upped whenever somebody does something within the repo, regardless of what branch the thing happens to.
I commit something to trunk, the rev number is upped to, say, 1337, and my new version is given that number.
I now branch trunk into /branches/mybranch. I do this by doing a remote copy of trunk. This copy of trunk, although identical to 1337, is a new version and is thus given the revision number 1338, the first revision on the new _branch_.
Now I commit a number of changes to trunk, spinning past 1339, 1340, 1341 and 1342 - each being separate _versions_ but on the _branch_ called /trunk (think of it as paths)
Now, if I commit some minor change to /branches/mybranch, what revision number will it get? You guessed it - 1343.
If I now commit something to trunk again, it will get 1344. I then commit something to the really old branch based on, say, revision 666. It will get 1345.
So, my point is: we really should stop talking only about revision numbers when we're trying to convey an idea of some kind of advancement of state.
Ie, in my example, 1344 is probably the one reflecting the most development, 1343 is essentially based in 1337 and 1345, currently the highest rev number, could basically be six months old, with just a minor modification.
Now on to tags - trunk, branches and tags are really all one thing: paths. The only real difference is by convention: there is a certain path called /trunk that serves a certain purpose, nemaly to be the focal point for developers. There is a certain name used for paths other than trunk, and that is "branches". Some branches by convention aren't meant to be modified, but serve as snapshots of a point in time - they are called "tags".
But to the server, they are all revisions along differerent link paths. There is really nothing stopping you from committing to a tag - it's just the svn client will be reluctant to do so, as it's aware of the convention.
Keep this in mind, when referring to a 'revision' - it might be on a totally different path, so be sure to mention what path you're really talking about. specifying "trunk, between revision 1343 and 1780" or "0.6.2 post-fixes, between revision 1764 and 2006" again lets you compare revision numbers to indicate advancement of state.
So, don't tell people to check a certain revision out, unless you mean _exactly_ that version - tell them the logical path to it instead.