This may boil down to opinion: I am wondering if project files (the files generated and used by the IDE and not the compiler) should be included in source control repositories. Are there certain cases where they should and shouldn't?
Edit: I should mention that the reason I am asking is because I'm looking at some lists of files to be ignored by git when using Visual Studio -- some of these lists have the project files and some don't.
If you have special build scripts it may be required for the IDE to build your project. Plus if you do a fresh checkout do you really want to go through the hassle of setting up all the project build parameters etc each time?
If you work with other developers and they don't use other IDE, or other versions of IDE, the IDE project files won't be the same. I think IDE project files should not be put under source control.
We use Eclipse and the only file we checkin is the .classpath file so that any classpath changes don't break the build on an update.
One simple question: Do you need them to build your code? If not, then they're artefacts, not source files, and have no place being in the source control system.
Things like your editor color preferences or keybindings are not part of the build system. Compiler flags and so on are.
We store everything that's needed to build, down to the operating system install disks and required configuration. Anal-retentive doesn't even come close to describing us :-) If we could store the hardware, we would (we have to make do with storing a document detailing the hardware specs).
We also occasionally test our capability to build the development environment from scratch using only what's stored in the repositories. Failure there means that we;re not covered in terms of disaster recovery.
It is easier and logic to me to include project files in the repositories, since they are part of the project itself. Project changes, project files too.
Whenever you have to revert the whole project to the previous state, or invite someone to check in to work on the project, it will be much more convenient to have every file. Not just source code.
By the way, most IDEs include the project files in repositories, and it will be too painful to exclude them and still keep the possibility to check in and check out from IDE itself.
Generally, project files should be version controlled but user preference files should be ignored.
For example when using Visual Studio, '.proj' and '.sln' files should be version controlled, but '.suo' should be ignored.
It really depends on your needs. We have several project files under source control, one for each developer, and several others for the automatic build. If your project isn't that big and you don't have different developers working on different parts of your projects, then you may not need such a setup. Project files needed for the build process should always be under source control.
Project files that include build instruction should definitely be under source control. You don't want to set correct compiler and linker flags and path on each fresh checkout, do you ?
However, not all project files are created equal, and some are just "helping files" that store tags or recently open files and so on. Those must not to be versionned, since they can vary for each developper.
There are two different benefit from versionning project files :
I'm working for a company who develops and selles an IDE. At the beginning we removed all project files away from the user directories. Most of the people were happy with this way. But from time to time someone asked if it is possible because they wanted to work also from there home system and use the version control as a fast file transfer utility synchronizing work and home place.
I can tell you that implementing this request was not easy!
The settings has to be clearly separated, for example if your IDE stores window coordinates in the settings file and you work on dual monitor system at work and a small notebook at home it is really bad. The IDE must also be able to provide a way to handle environment variable expansion in every file path. And finally of course it must be able to give setting files individual names or store them in different places - otherwise you will soon find out that 3 different developers on the project have 5 different opinions about fonts, colors, default values etc. because if this is not well done they will all use the same settings.
On the other hand many IDEs have huge amounts of data to store, some of them even store GUI configured unit test cases in project settings. In this case it is of course useful to reuse the files and check it into the version control system.
So you see it depends. Try it out and see how it works for your environment.
For .NET, I think the project files should be included in the source control repositories. In C# and VB it's the project file that defines which source files that are part of the assembly. If you add a source file to the project and don't have the project file under source control, all other developers in the team must manually add the file to THEIR project.
In Java all files in a source tree is automatically included in the build (if I remember it correctly) so the need for a project file may not be the same in Java.
Yes, I believe IDE project files should be committed to Subversion as most of this includes configurations on how to build/compile the project.
If there configurations that are solely used to store developer preferences outside of the coding convention then those must be taken out (i.e. excluded) so as not to introduce confusion.
Not sure if it was mentioned, but Visual Studio (at least the C++ version) produces two project files: