In SVN, $Revision$ should be the same for every file in the project so they would all have the same $VERSION.

This falls apart when you use helper modules/libraries. In order to maintain these files across projects, you need separate copies (which will quickly get out of sync).

Distributed version control systems, such as SVK, may have a different $Revision$ based on who checks out the file leading to a different $VERSION on each machine!

This is more a management problem than a technical one. Team members should follow a procedure where builds are only done after checking out updates (if individual modules are used as opposed to a "library" type file that is linked to).

Finally, some distributed version control systems, such as darcs, have no concept of revision number at all.

If there is "no concept of revision number", this is not strictly a version control system (IMHO).

What tips do you have a automatically managing version?

Choose one system and use it across all projects. When you use multiple ways of tracking changes, some will get lost in the shuffle (think Murphy and his friends).

What about using $Date$ for versions? eg. 2008.02_18

This works, if a master list is maintained of what changes are made and in what order.
The major strength of a revision control system is the ability to revert changes to a known point. This is why most will only allow a module to be checked out for update by one person.
When a date variable is used to denote revisions, this can make it difficult to manage a multi-tree project (ie: development, test, production). It also makes it difficult to distinguish between major versions (ie: text mode, GUI, client/server). While ideally the back end should not matter, this is rarely the case.

Above all, remember:

In theory there is no difference between theory and practice. In practice there is. (attributed to multiple people with slight variations)

Good luck with your project.