When it comes time to do a release you tag the revision so that you can always see a snapshot of the repository as it looked when you did the release. SVN does this by doing a "soft copy" which means it just stores the revision numbers of every file into a different folder (the tags folder). This looks like it's copying your entire repository, but it's actually just copying revision/file markers.
Take a peek into
BUG's tags folder. You can organize this folder any way you like. For BUG I created a "releases" folder in case I wanted other tags, which I later did want for BUFFY. It pays to plan ahead. The releases folder has one tag for each release I've done (I took over the release process with v3.0).
Making a tag is very easy, especially with a tool like TortoiseSVN. Just right-click your trunk folder and say "Create Branch/Tag", name it and put it where you want.
Branches are for when you want to have two different (forked) development versions. Let's say that you're working on your mod and someone comes along and says, "I want to add feature such-and-such, and it may take two months to add so I want to commit occasionally to the repository." You know those commits won't be fully working, so you don't want them mixed in with the work you're doing in the trunk (main day-to-day line of development).
So you create a branch (again another soft copy) for that developer in the branches folder, say "experimental-feature-tango" for brevity.

Now they can work in that branch folder just like it's the trunk. Once they have completed it you would merge it back into the trunk--just like using WinMerge to merge two mods together--and delete the branch (or keep it, it really makes no difference).
Granted, these are probably not thing you are going to need to do today or tomorrow, but eventually you'll want to do them. If you have those (empty) folders now, there's no cost and a huge payoff when you're ready for them. For now, just pretend they don't exist and do everything in trunk.