Project files in repository

Question

Is it common practice to keep project files (i.e. files other that source code files) in the version control repository?

Also, are these files checked in/out on a regular basis?

I always envisioned a SCC repository as 'clean' with only source code files.

How do you manage the non-source code files in a repository?

Take a Visual Studio solution, as an example. Would you "check-in" the entire Solution's directory to the SCCS or would you just add the source code files? What about when it comes time to build the Solution, then the entire solution needs to be checked out? Maybe it's best done with a manual process?

Answer 1

I think the general rule of thumb is that the minimal amount of data required to make the project compile and run should be included. That includes art (or other basic data files) and any build scripts. In the case of an autotools project, this usually means a configure.ac. In a Visual Studio project, it means the Visual Studio project file. But you wouldn't include anything that can be automatically generated from the rest, for example a "configure" script, if a configure.ac is already there.

CVS and Subversion both have flags for adding binary files (Subversion adds it automatically), which is great for things like images and project files (the binary ones, anyway). Subversion also allows for file locking, which can be good for artists who don't want to clobber each other's work.

Answer 2

Typically anything that is rebuilt as part of the build is not checked into the respository. Otherwise there will be merge conflicts when the generated files are committed, especially if they are binaries or contain absolute paths.

As Sydius mentioned, most SCM tools have a way to flag non-source files as binary. Most modern tools auto-detect non-plaintext files and for CVS it is:

cvs add -kb filenames

Answer 3

You should keep everything that you need to build the project within the repository.

So source code needs to be kept, but also things like the help files, documentation, graphics, licence, etc.

The final product does not need to be stored, because it is rebuilt from the source.

Also, configuration files with passwords and logins shouldn't be stored either.

Answer 4

Anything that can be generated from other files in the repository should not itself be stored in the repository.

Answer 5

One of my pet projects is a small cross-platform application for Windows, Mac OSX and Linux. I use wxWidgets as framework and Kdevelop on Linux, XCode on Mac OSX and Dev-Cpp on Windows as IDEs. The project files for each of these IDEs are perfectly manageable with CVS and SVN. I keep the project files in the repo. Whenever i have to rebuild the development environment on any of the target platforms, all i have to do is install the IDE and check out the latest CVS.

Answer 6

Yes, you should! You should include all the files necessary for other developers to quickly set up the project in the IDE, including yourself to quickly restore the project if you happened to mess up your local project configuration.

I'm mostly into web development. There are project resource files, such as Photoshop .PSD files, that are used for development and are somehow exported into other files that go into production. You may want to keep them in a separate folder or repository. Project members who aren't mainly concerned with those files, they're rarely updated and maintained by few people anyway, can opt to ignore those resources and not have a local copy.

Answer 7

You need keep history of compiled binaries as separate archive. If you do update on a server and it does not work you need to rollback. Much better if you do it from archived binary copy. I think it is good idea to have some routine for binary version control. But they are not supposed to be stored under SVN or alike. SCC systems are most useful then they are used not for backup purposes but for rollback and to keep track of change sets inside of stored documents. Which does not make sense for binaries.