You're mixing together some separate concepts (as you found out with the annotate sub-command). Annotation (git annotate, svn annotate, and so on) or sometimes called "blame" asks the VCS to show you information about both the source itself and the earliest revision that had that particular source fragment—usually a line, since we mostly deal with "lines of code"—in the same form as it does in one particular revision.
But that's not what you are still looking for, so let's dive in. All version control systems have a problem: if you are going to store every version of every file, you could require huge amounts of storage-space.
Most VCSes therefore use some kind of compression, and most immediately jump straight to using delta encoding, also called delta compression: store one version fully intact, and instead of storing a second version intact, store only a set of instructions that can be used to modify the stored-intact version in order to obtain the second version.
Repeat this for many versions and you get chained deltas, where you start with some initial version and repeatedly modify it to get a final version. Initially, SCCS used this in a "forward" direction: store the initial version, then store the first change to it as the second version, then store the change to the second version as the third version, and so on. This, clearly, is somewhat slow. RCS therefore uses reverse deltas: store the latest version intact while storing deltas to compute earlier versions from their successors. This makes retrieving the most recent version fast, and the oldest version slow—usually what one wants—but it has a different drawback: it doesn't work properly with branches. RCS therefore actually uses reverse deltas on its trunk and forward deltas on its branches.
Since CVS is (or was) built atop the RCS file format, it too uses this reverse-yet-also-forward delta storage format.
For performance, modern SCCS uses a concept known as interleaved deltas, where the repository stores what amounts to a sort of union of all versions. A linear pass through a stored file suffices to extract any particular version. (The linked Wikipedia page says Bitkeeper also uses interleaved deltas.)
I don't personally know what Subversion uses internally, but How exactly does subversion store files in the repository? suggests it uses reverse deltas plus snapshots. Baking in a snapshot—another "fully intact" version—now and then provides a way to set a limit on the number of deltas to apply.
Git does something fairly different. Instead of storing each file separately and delta-compressing against previous versions of that file, Git stores what it calls objects. Each object is, at least logically, stand-alone (a snapshot)—so that no version of any file is ever delta-compressed, though each snapshot is zlib-compressed. To save additional space, Git occasionally compresses multiple objects into a single "pack file", and here the pack file internal objects do get delta-compressed ... but against any other objects, not just ones that represent the same source file. (In particular this allows Git to compress tree objects using other tree objects.)
In the end, what this means for Git is that it uses delta-compression, in potentially any direction—this might be mixed forward and reverse—with snapshots to keep chain lengths limited (--depth or pack.depth), but of objects against objects, not necessarily just one file against another version of the same file. For practical purposes, Git does not choose these objects totally arbitrarily (it's too hard to know which objects will compress well with other ones in advance) but instead does it by object type, object size, file name as found in a tree object, and age (I'm not sure where it gets these ages from), so that Git often winds up with the equivalent of reverse deltas, but it's not guaranteed. (Git also re-uses precomputed delta chains from previous packs unless you tell it not to; see --no-reuse-delta aka -f.)
As a general rule, there's no way to tell a revision system to completely revamp its internal storage format. Some VCSes may have exceptions. For instance, Git is a bit unusual since git repack does exactly that, but not in a way that's useful to your particular use case!
