I tend to delete comments in code. And by delete, I mean, with prejudice. Unless a comment explains why a particular function does something, it goes away. Bye bye. Do not pass go.
So it shouldn't surprise you that I would also delete those changelogs, for the very same reason.
The problem with commented out code and comments that read like books is that you don't really know how relevant it is and it gives you a false sense of understanding as to what the code actually does.
It sounds like your team doesn't have good tooling around your Version control system. Since you said you're using Subversion, I'd like to point out that there's a lot of tooling that will help you manage your subversion repository. From the ability to navigate your source through the web, to linking your changesets to specific bugs, you can do a lot that mitigates the need for these 'changelogs'.
I've had plenty of people comment and say that perhaps I'm in error for deleting comments. The vast majority of code I've seen that's been commented has been bad code, and the comments have only obsfucated the problem. In fact, if I ever comment code, you can be assured that I'm asking for forgiveness from the maintanence programmer because I'm relatively certain they'll want to kill me.
But lest you think I say that comments should be deleted in jest, this Daily WTF submission (from a codebase I worked on) illustrates my point perfectly:
/// The GaidenCommand is a specialized Command for use by the
/// CommandManager.
///
/// Note, the word "gaiden" is Japanese and means "side story",
/// see "http://en.wikipedia.org/wiki/Gaiden".
/// Why did I call this "GaidenCommand"? Because it's very similar to
/// a regular Command, but it serves the CommandManager in a different
/// way, and it is not the same as a regular "Command". Also
/// "CommandManagerCommand" is far too long to write. I also toyed with
/// calling this the "AlephCommand", Aleph being a silent Hebrew
/// letter, but Gaiden sounded better.
Oh... The stories I could tell you about that codebase, and I would, except that it's still in use by one of the largest government organizations around.
Tags and branches aren't mutual, you can (and IMO usually should) use them both. Tags are there to mark milestones in development. E.g. you open a branch for version 1.2 of your product, and you mark v1.2 Beta, RC1, RC2, Final (and then, if needed, SP1 etc.) with tags on that same branch.
I personally prefer Method 2 as the default approach (although I try to avoid multiple levels of branches, to keep life as simple as possible). Method 1 is just not going to work in real life - tags aren't enough, you need branches. And method 3 is inflexible in that it has only a single stable version at all time, so (unless you combine it with Method 2), you can't maintain multiple (latest and older) versions in parallel. This is required for almost all projects in real life - while you are working on version 2, you should still be able to publish patches / upgrades for v1.9, and often even earlier versions. A lot depends on the type of application of course. We develop a web app, so there is only one production version at any given point in time, still we often juggle with 3 different versions (one in production, one is in UAT getting ready for deployment, one is the latest version on the trunk). It can get way more complex for a desktop/client app with multiple older versions being used - and maintained - in parallel.
Best Answer
I come from the side that believe commits should be frequent. Exactly how frequent will depend on your personal development style. Some in the TDD world will commit every few minutes (each completed cycle), others perhaps a few times a day at what they feel to be a good point. Some benefits of frequent commits are:
Instead of branching you can use feature toggles. These can be used to keep your feature hidden on separate code paths until it is ready to be revealed. However this does introduce some complexity and extra overhead, so it's generally not worth doing this for small tasks.
I'm unclear what you mean by "if a problem is found, you can address the issue as quickly as possible". Commits are quick and cheap, you fix the bug and make another one (commit, not bug). If on the other hand you mean "oh no I've found a major problem with my feature and want to pull the whole thing from the build", feature toggling can also help in this regard, as you just switch it off.