When working on relatively small projects, but a software requirement specification document is necessary, is it a standard to include said document on version control systems or is it managed differently. Note I'm talking about standards
SRS Document – Version Control Best Practices
project-managementversion control
Related Solutions
Yes.
All it takes is a single mistake and you'll be kicking yourself for it. You're also in the position to choose which version control system (VCS) is used. If there is any possibility that you'll work in a development team in the future, this is a great time to give yourself hands-on experience with a VCS. SVN and Git (or Mercurial) would be great starting points and should only take a couple of hours to grasp the basic commands in each VCS.
Now to debunk what the negative points...
1) Additional resources required
The only resource required is disk space. Since this is a small percentage (smaller in Git than X) of your total code, I don't think this will be an issue. It doesn't cost any money either.
2) Time to setup, get used to it, etc.
There will be time required to learn it, but it is only a few hours for each of these (as mentioned above). On the longer term, it has the potential to save you an infinite amount of time (and so much more). Once you've mastered the basics of a VCS, it will be far less finicky than performing the local backup you have in mind.
Don't ask him. Don't tell him. Show him.
Install svn, or git, or whatever you like on some extra machine. Practice using it yourself until you feel comfortable not just using it, but explaining it. If you're going to make him comfortable with your new system, you'll need to be more than comfortable with it yourself. You'll need to be able to help him recover easily when he screws up a merge or checks something into the wrong place.
When you're ready, show him exactly what you're talking about. Show him that it doesn't "make a mess" of anything. Point out that it doesn't just let you retrieve any previous version of your code with ease, it also makes it possible to know exactly what changed between any two versions.
Point out that if anything ever happens to the server (serious bug, virus, hacker, disk crash...) you'll both look like heros if you can instantly reconstruct the necessary version. Point out, too, that you'll look twice as good if you're able to produce any version on demand. Search your old e-mail and compile a list of problems you've had over the past year that you could have avoided with version control.
Give him a cheat sheet that will make it easy for him to use your version control system.
Finally, suggest some options but leave the decision to him. Should you set up your own server, or use one of the many hosted services? Should you use svn, git, or something else? Should you migrate all seven projects to the system, or try it with one or two at first?
Best Answer
Yes and no. Version control is about just that: control of revisions of assets, be they source code text files, images, or even documentation. While software engineers usually put source code and graphical assets (once they receive them) under version control, graphical assets and standards documents are often prepared by non-engineers. In my experience, these people rarely work under version control (though it could be argued that they should).
Another reason why requirements specifications are not often under version control is that they are often not text files (Word documents, spreadsheets, or Google documents are common) and thus versions cannot be compared easily by many version control systems. Yes, modern word processors can intelligently compare different revisions, but sometimes that feature cannot be invoked by the version control system.
In spite of this, there is a natural tendency for people to understand the importance of preserving old versions, and I have seen various ad hoc methods used by non-engineers, like adding revision numbers or dates to the filenames, for instance.
You ask about standards, and I know of no commonly-applied official standards requiring which assets need to be under version control and which do not. This is a managerial and organizational choice, and it varies from place to place. Some enterprises have clear policy around this, using in-house or externally-defined guidelines, or special software tools, others do not.