You only want to *avoid* storing such things if they are being generated from a tool such as CMake, due to the reasons I mentioned above. Namely, if you store the project files and someone changes them, then someone else regenerates the project file from CMake, it will overwrite those changes. Instead, you want to encourage the first guy to make the necessary changes in the CMake configuration, and a good way to do that is to make sure that the VSProject files are never checked in. Every time the CMake config is updated, they have to get the latest version and re-run CMake to generate the new VS file. This also allows them to muck with their own project files without worry of breaking everyone else -- this lets them test out new configs locally before committing them to the CMake config for all to use.


If your project *only* targets visual studio as its development environment, then by all means go ahead and store the project and solution files -- the ones you have to watch out for are the machine or user-specific files -- things such as IDE customization and that sort of thing. Another caveat is that if you store the solution, and the solution names a dependency on lets say, Boost, which is referenced by the full path "C:/libs/boost/1_49" or something, then *everyone* that builds must also install boost at that exact path (they can't have it somewhere else, otherwise they'll need to change the path in the project file for theirs, and when they check in they break everyone else's build.

On way around this is to come up with a standard directory structure for these sorts of dependencies (3rd party libs, SDKs, tools, etc), and create on each machine environment variables for each relevant section -- On my machines, I define the environment variables DEVBIN for tool binaries, DEVSDK for SDKs, DEVLIB for libraries, and DEVSRC where I store all my projects. Of course, the structure of each has to be identical across machines, but at least this way I can move them anywhere on my hard disk -- for example, on my desktop I keep this stuff on my raided drive E, but on my laptop I don't have a secondary drive or partition, so its all on drive C.

This is a good middle ground between full user-centric customization and enforcing a strict machine format.

Thanks for the reply Ravyne. I think you've misunderstood my question though. My issue was where to create the project files on my PC - in with the repository folders or in a separate folder:


[color=#1C2837][size=2][font=arial, verdana, tahoma, sans-serif][size=2]I have a root folder "E:\Dev\Projects\SSZS". This folder will store the entire project. It has two folders inside it, "project" (the Visual Studio project) and "repository" (the project hosted on SVN). This seems like a nice structure because you don't mess up IDE-specific stuff with the repository stuff. The only problem is that if I run the code below, it can't find the font file because I'm running the application from within a separate folder to the repository folder:[/font]
[font=arial, verdana, tahoma, sans-serif][/font]
[color=#660066]MyFont[color=#666600].[color=#660066]LoadFromFile[color=#666600]([color=#008800]"gui\\fonts\\arial.ttf"[color=#666600],[color=#000000] [color=#006666]50[color=#666600]);

What is the way around this? Do you keep your IDE project in with the repository files?

The "working directory" of your executable is configurable. When you double-click an exe in windows, it will be the exe's directory. When you double-click a shortcut, it will be the directory specified by the shortcut, and when you run an EXE from visual-studio, it will be the directory specified in the [font="Courier New"]project properties -> debugging[/font] dialog.

In most projects, you usually have to go into that directory and manually choose a different working directory, because visual studio's default (the project file's directory) is usually wrong.
However, it's also quite common for games to have a command-line option that specifies where the data directory is, e.g. you could run your game with [font="Courier New"]myGame.exe -data d:\mygame\bin\data\[/font], and then when your code executes [font="Courier New"]LoadFromFile("gui\\fonts\\arial.ttf")[/font], the game will turn it into "[font="Courier New"]d:\mygame\bin\data\ui\fonts\arial.ttf[/font]", and then file-loading will still work even if the working directory is wrong.

Why don't you want to store the project file inside the repository though? What makes it not a "repository file"? If someone else downloads the repo, won't they need the project files in order to build the project?

The "working directory" of your executable is configurable. When you double-click an exe in windows, it will be the exe's directory. When you double-click a shortcut, it will be the directory specified by the shortcut, and when you run an EXE from visual-studio, it will be the directory specified in the [font="Courier New"]project properties -> debugging[/font] dialog.

In most projects, you usually have to go into that directory and manually choose a different working directory, because visual studio's default (the project file's directory) is usually wrong.
However, it's also quite common for games to have a command-line option that specifies where the data directory is, e.g. you could run your game with [font="Courier New"]myGame.exe -data d:\mygame\bin\data\[/font], and then when your code executes [font="Courier New"]LoadFromFile("gui\\fonts\\arial.ttf")[/font], the game will turn it into "[font="Courier New"]d:\mygame\bin\data\ui\fonts\arial.ttf[/font]", and then file-loading will still work even if the working directory is wrong.

Crazy. I've never used that in all the years I've been programming... it sounds like it will solve that problem. Thanks!

Why don't you want to store the project file inside the repository though? What makes it not a "repository file"? If someone else downloads the repo, won't they need the project files in order to build the project?

I'm still very new to the whole repository thing, as well as CMake (I don't think it's fair to restrict what IDE is used, especially as we have at least on person on a Linux system), otherwise I'd be storing project files in the repository. I'll need to learn how to use CMake to create the CMake lists or whatever in order to generate project files for each IDE... most people have more trouble getting third party libraries set up than getting their IDE project files set up, so I'm not particularly worried about it at the moment.