views:

79

answers:

4

Which Visual Studio \ Visual C++ file types should be committed to version control?
In my project I have the following file types:

aps
cpp
exe
filters
h
ico
idb
ipch
lastbuildstate
lib
log
manifest
obj
pch
pdb
rc
rc2
res
sdf
sln
tlog
txt
user
vcxproj

I would greatly appreciate a short reasoning for each. If any of them are controversial, please note it. I'm intentionally including even trivial file types for completeness.

EDIT

On one hand I would like to be platform independent in the future. On the other hand in the near future I would like to work with team members with similar setups. Folder compatibility between the setups is certainly an option, so configuration files holding paths may be included if it eases the workflow.
Again, I would surely appreciate an explanation what's what.

+1  A: 

Only the onces that are required for building your target. I think this is just .cpp .h .ico .rc .txt .manifest .rc2

I don't know what sdf, aps, filters, user is, haven't seen them in my C++ builds.

Just look and find out if they contain programmer written code or if they are generated by VS.

Lothar
.sln and .vcxproj are needed for sure - they describe the project and the solution.
sharptooth
Yes, if you don't maintain makefiles. Sorry i'm personally so Anti-VS/MS that i forgot that there are people using the Visual Studio as the only tool for their developmen. I'm only using the debugger.
Lothar
well, the VS project files are makefiles too
milan1612
+4  A: 

From your list I'd choose those:

cpp
filters
h
ico
manifest
rc
rc2
sln
txt
vcxproj

Generally, you should version all files necessary to build the project. Automatically generated files should not be archived imho.

milan1612
@milan1612 thank you for the concise list. Compared to Hans Passant's answer, you said I should commit manifest files where he said I shouldn't. Could you elaborate what this file means and why do you think I should commit it, especially in a team (and future cross-platform) environment, if that's relevant?
Jonathan
manifests can have different purposes. I've had manually created ones included into a resource file that caused windows to apply styles to my window. also, there are manifests that enable you to deploy the standard library dlls alongside your executable. think of meta-data about your application...
milan1612
+3  A: 
  • aps, no: last resource editor state
  • cpp, yes: source code
  • exe, no: build result
  • filters, yes: project file
  • h, yes: source code
  • ico, yes: resource
  • idb, no: build state
  • ipch, no: build helper
  • lastbuildstate, no: build helper
  • lib, no: build result. Can be 3rd party
  • log, no: build log
  • manifest, no: build helper. Can be written yourself.
  • obj, no: build helper
  • pch, no: build helper
  • pdb, no: build result
  • rc, yes: resource script
  • rc2, yes: resource script
  • res, no: build helper
  • sdf, no: intellisense dbase
  • sln, yes: project file
  • tlog, no: build log
  • txt, yes: project element
  • user, no: debug settings. Do preserve if just one dev or custom debug settings
  • vcxproj: yes: project file

Several of these are iffy because they can both be auto-generated and maintained yourself. And there are several more that don't appear in your list. Primarily pay attention to the location of the file. If it is in your solution or project directory then it's highly likely you want to check it in. In the Debug or Release subdirectories then highly unlikely. Build + Clean removes a lot of the noise files. And of course: check-in, rename the project directory, check-out and verify that it builds.

Hans Passant
Thank you for the details ;) Compared to milan1612's answer, you said I should commit aps files where he said I shouldn't. Could you elaborate what this file means and why do you think I should commit it, especially in a team environment, if that's relevant?
Jonathan
Not 100% sure, I haven't used the resource editor in a long time. Follow the 2nd rule, pay attention to where it is stored.
Hans Passant
On second thought, I agree with milan. The important state (last ID used) is already in the .rc file. It should be able to recreate the .aps from that.
Hans Passant
Odd, you ask for a description but then accept an answer without any at all. I'm sorry I wasted my time on it. Hopefully useful to somebody else.
Hans Passant
A: 

If you right click over the project there should be a "Add Solution to Source Control" option in the context menu.

If you use this, only those files that are necessary will be added. All the intermediate and output files will be ignored.

ChrisF

related questions