You don't assign version numbers when checking in changes. The version control system has its own internal version numbers. You don't need to know what they are, and they have little relevance for typical work. At best they're a handy short name for what is better described by the commit messages.
The 3 dotted numbers,
Semantic Versioning, is what you'd use for tagged versions when doing a release. This has no resemblance to the internal version numbers used by normal everyday commits. Don't worry about it at this point. I don't think you need it, and even if you did, it's something you can learn and do after the fact since you're just tagging existing versions (identified by a single auto generated number) with a human made tag.
The commit messages aren't written into a separate document along with the rest of your files. The notes are attached to the commit, and exist separately from the files under version control. If you're using TortoiseSVN, there is a dialog box that pops up when doing a commit which has a text box for your commit message, and also displays a summary of all the changed files that will be included in the commit. If you're using svn from the command line, you'd specify the commit message as a command line option.
svn ci -m "Commit message here describing the changes for this commit"
Ideally commits should be small and often. Not every commit needs a public release. Releases to the public, which occur less frequently, can become tagged versions. You don't need to worry about tagged versions and releases at this point.
Ask Leviathan for an account with write access, and grab a copy of
TortoiseSVN. It's actually quite straightforward to use, and comes with good help and examples. I can always walk you through the process once you're setup with an account and the software.
