The log files in question are metrics log files. One of them is a project file produced by SourceMonitor, to which I regularly add checkpoints to chart the progress of projects.
Version Control – Should Log Files Be Stored?
version control
Related Solutions
Software configuration management, of which Version Control is part, is a little more complex than keeping track of changes to files, although you can certainly start with that. But do read the Wikipedia articles linked above along with Joel Spolky's tutorial on Mercurial.
To start, choose one of Mercurial, GIT, or Bazaar, in that order, and install it along with tools for your IDE and operating system (I prefer Mercurial with HGE for Eclipse).
- Initialize a repository from your working directory (hg init with Mercurial)..
- Decide which files and directories you want to track and which not. The general rule is not to track files that are generated by compilers and other tools.
- Use the command to add the files and directories to the repository (hg add for Mercurial).
- Tell the tool about the patterns for the files you don't want to track (edit .hgignore for Mercurial).
- Perform a commit to track the original versions (hg ci).
- Perform a commit after each logical milestone, even if it's a small one.
- Add new files as you create them.
- Repeat the last two.
- Backup your working directory and the repository as frequently as reasonable.
With your files in the repository, you can know the differences between any two versions of a file or directory, or the complete project (hg diff), see the history of changes (hg hist), and roll back changes (hg up -r).
It is a good idea to tag (hg tag) the repository before publishing your code so there's an easy way of going back to exactly what you published for amendments or comparisons.
If you want to experiment with a different line of development, do it in a simple branch by cloning the main repository (hg clone) and not pushing back until the experiment is conclusive. It is as easy as having a different working directory for the experiment.
If the experiment is for a new, upgraded version then clone and then branch (hg branch) so you may keep all copies of the repositories updated without one experiment interfering with the other.
Linus Torvalds (who deals with tens-of-thousands of files and millions of lines of code in his projects) gave a talk at Google about why the tool can't be CVS, SVN, or any of the many free and commercial ones around; it is very much worth watching.
It looks like you you saying that a file with unresolved conflicts breaks Gamemaker.
Well, I'd expect that regardless the file type or system. You need to resolve all the conflicts before building. There's no way that having a file marked with unresolved conflicts can keep the structure of that file valid.
If this was a C# or Java source file I'd expect to get compiler errors if I tried to build the project with the file in this state.
Best Answer
Nowadays storage is cheap. If these are metrics that you can use to show performance increases that coincide with versions, then I'd say keeping them in source control is just fine. Just make sure that you're storing them for a reason. If you can regenerate these logs/performance files from the source (meaning I can check out the code, run it, and produce the exact file you're about to store), then you probably don't need to.
Lots of things are stored in version control these days, including any and all documentation and other files that change along with the version of the project/code.
Note: You would store these in a branch outside your code branch. Like Thomas' answer states, the source code branch that is used to build/deploy the app should be be separate so that your build server (or you, if you don't have time/space) can download/checkout the code independently of the documentation.