I have a mixture of small and large projects in SVN. Some of them are so small I can't ever foresee myself branching or tagging.
So, should I still stick with the trunk/branch/tag folder convention even if I'm fairly certain the branch/tag directories will go unused for the smaller projects? I just feel like it might be overkill.
Thoughts on this?
To answer the question in your title directly: no, you don't have to. SVN repositories can be organized in any folder structure you choose.
That being said, it's probably a good idea to at least put everything in a trunk folder for now, so that if later on you change your mind and decide that branching or tagging would be useful, you can add branch/tag folders easily, without having to move everything around.
They're convention, so what does it hurt to add them. If your project gets to the point where you need them, then it's much easier to have them in place from the beginning than to try to add them in after the fact.
I use the branch/tag/trunk directories in Subversion even for trivial projects. It's pretty much zero cost and is worth it in consistency. I always know how my project is going to be laid out if I ever need to do a checkout.
In my SVN repository I have a single trunk / branch / tag directory. I put all of my projects in trunk and organize my branch and tag directories separately based on the projects that actually reach a taggable state. Convention might suggest using a branch / tag / trunk directory for each project however that can be impractical if you don't expect to be tagging and branching.
Even personal projects can benefit from infrequent tagging and branching before major rewrites or after a long hiatus.
Typically (or quite obviously), branching/tagging are extremely useful in teams, where many coders will be working with the source at the same time. Each coder works in their own branch so there's no risk of saving over someone else's work.
As a one-man-army developer, I've still found branching/tagging useful when:
I need to make an experimental branch without giving up on the current working source. I'll merge it back in if the experimental code proves better.
If I have several separate components, it may be useful to tag each one with a name denoting project version number and put them in a tag folder named after the project. This helps keep tabs when you want to go back to version 1.0.5.10 and need to know what changed in component Foo. The commit notes may not be informative enough.
In my experience, the 'trunk/branch/tag' organization is a pretty well-used layout for source control. I've seen it implemented in a number of different organizations using different tools (ClearCase, SVN, CVS, to name a few). The ClearCase setup I currently work with is slightly more sophisticated (convoluted?), but, generally speaking, followed a very similar layout.
Though it's not required in SVN, I would highly recommend becoming accustomed to this type of layout, including merging to/from different branches and the trunk.
For personal projects, I find tagging to be a valuable means of preserving final, immutable releases. Branches are typically reserved for experimental tangents so I won't destroy the most recent (stable) version of my code before reality kicks in.