0

I want to version my visual studio 2010 debug builds. I'm going to use git. Right now all the project files are in 'project' and the output binaries are put by visual studio in the directory 'project\debug'. I've read a few questions on here that have ignore lists for Visual Studio but most of them have an ignore list that ignores the binary files, like the obj exe idb pdb ilk etc.

If I want to be able to debug my exe in the future what files do I need to keep? Is there any reason to keep the obj files? Does VS use them at all during debugging or tracing a crash? I thought I should keep at least the the pdb files and the exe. So that would be project.exe, project.pdb and vc100.pdb. But what about vc100.idb, project.ilk, project.res... etc. Is there an ignore list that will ignore everything that isn't needed to keep binary builds but keep everything that is?

I want to make sure if a user sends me a crash dump or reports a problem at some point in the future that I can go back to the version that was being used and be able to debug it. I had also hoped to make the binaries and debug files available in a remote repo so that anyone else could as well. Thanks!

loop
  • 3,460
  • 5
  • 34
  • 57

2 Answers2

3

Don't keep binaries in version control. Instead, build from source.

Since the binaries are built from source, and you have the source versioned already, just re-build the particular version as-needed. It will both keep your version control system lean and fast, as well as not cause merge headaches (which binaries are notorious for).

So, the answer is don't keep any binaries in version control.

If you feel you really must keep them, however, then just zip them up and store them like normal files using the tag of the build they came from.

cdeszaq
  • 30,869
  • 25
  • 117
  • 173
  • But I want to keep my binaries in version control. They are in a separate branch and I know how to deal with merge conflicts. – loop Jan 19 '12 at 20:35
  • _why_ do you want to keep the binaries in VC? If you are not interested in _how_ they changed, then just keep them in the file system, since they are separate, distinct files. – cdeszaq Jan 19 '12 at 20:38
  • 2
    Use your version control and version numbering scheme so that if a bug report is submitted, you can easily build a version that matches. Don't keep binaries in source control. – Adam Baxter Jan 19 '12 at 21:19
  • @cdeszaq It's easier for organization. – loop Jan 20 '12 at 04:34
  • 1
    But the penalties you pay for having a bloated repository out-weigh the benefits. DVCS isn't particularly well suited for large binary blobs. SVN is able to handle them better, since it doesn't need a full repo copy on the local machine, but it's still not the ideal tool for this job. – cdeszaq Jan 20 '12 at 13:36
-2

I'm going to keep project.exe and project.pdb in the branch. The other files like *.obj, *.ilk, and *.sdf are not needed. Neither are the vc100.* files. I made my decision after speaking to a number of people in person and reviewing this:

File Types Created for Visual C++ Projects

and this:

Which Visual C++ file types should be committed to version control?

Although that SO question/answer does not answer my question it gave me a lot of good information. I also looked through my project.pdb for all the file references to confirm which files in my project that I needed to keep around. I used this command from the debugging tools for windows:

srcsrv\srctool -r project.pdb

Community
  • 1
  • 1
loop
  • 3,460
  • 5
  • 34
  • 57
  • 1
    You've asked a question and now told us what you are going to do, but don't explain why. *Why* do you think some files are required (.pdb) but others aren't (.obj, sdf etc). You also have said its easier for organization but don't explain why. Easier for you? Easier for your company? – Christian Payne Jan 26 '12 at 11:09
  • @ChristianPayne I think that's a fair point and I will update my answer. – loop Jan 28 '12 at 03:12