16

I am working on a small project, hosted on Google Code, using SVN for source control. This is my first time using source control, and I'm a bit confused about what I should actually be committing to the repository. My project is very simple: A Class Library project, written in C#. The actual code that I have written is a single file.

My question is this: Should I be committing the entire project (including directories like Debug, Release, Properties, etc.) or just my main .cs file?

After fighting with Subversion for a while (note to self: do not reset repository), it looks like I finally have it working with the directories laid out properly.

Cœur
  • 32,421
  • 21
  • 173
  • 232
Chris Laplante
  • 28,157
  • 16
  • 93
  • 131
  • 3
    Debug and Release have output files in them, not source files, so they should not be committed. The Properties directory has source code in it (AssemblyInfo.cs). If you follow Andrew's answer, you'll be fine. I just wanted to call those out explicitly, since you mentioned them. – Merlyn Morgan-Graham Dec 28 '10 at 01:08
  • 1
    @Merlyn: Thank you for the tip! – Chris Laplante Dec 28 '10 at 01:17
  • Well, actually... Here's a trick I've done in the past. I copy only the files I think I need for sure to another directory. Start with your csproj and sln files, and those files you see in Solution Explorer (make sure to drill down all the way). Then open that copy of the solution in VS. If it builds correctly (no errors, and all output files are the same), then those were the files you needed. Make sure you either a) write down the files you copied, or b) make *two* copies, one of which you use to test your clean build, the other you don't touch, and eventually check in – Merlyn Morgan-Graham Dec 28 '10 at 01:31
  • 2
    **Duplicate of long standing:** [What should NOT be under source control?](http://stackoverflow.com/questions/1273921/) **Related:** [Should I store generated code in source control](http://stackoverflow.com/questions/893913/) [Do you source control your databases?](http://stackoverflow.com/questions/115369/) [Should a .sln be committed to source control?](http://stackoverflow.com/questions/1033809/) [Storing third-party libraries in source control](http://stackoverflow.com/questions/49196/) [How do you deal with configuration files in source control?](http://stackoverflow.com/questions/6009/) – dmckee --- ex-moderator kitten Dec 28 '10 at 03:44

6 Answers6

14

You should commit everything but your output files.

This means commit everything except for your \bin and \obj directories (and the files in them).

Andrew Hare
  • 320,708
  • 66
  • 621
  • 623
10

For ordinary development I don't commit:

  • bin
  • obj
  • *.user
  • *.suo

Everything else I commit. For a release that will be sent to a customer I also commit the exact binaries that I sent.

Mark Byers
  • 719,658
  • 164
  • 1,497
  • 1,412
10

You should include everything required to build the project, not anything that the project produces since someone recompiling it will be able to produce those by compiling.

In the case of a C# project that is your solution file (.sln), your project file or files (.csproj), and your source files (.cs) and any resource files (.resx, *.bmp, *.png, etc.). That does include the files in the Properties folder, because those contain global settings for your project.

You do not commit anything in the Debug/Release, those are outputs of building your project. As a rule of thumb, you don't commit binary files (*.dll, *.exe).

As a test if you have committed enough, check out the source to a different directory on your computer and attempt to rebuild the project.

shf301
  • 30,022
  • 2
  • 46
  • 83
  • 3
    +1 for "As a test if you have committed enough, check out the source to a different directory on your computer and attempt to rebuild the project" – Merlyn Morgan-Graham Dec 28 '10 at 01:35
3

You definitely don't want to commit the built libraries, no. Source control is really just for the source. Now, in something like a .NET project setup you can also consider the project file(s) and solution file(s) to be source, that's fine. (But not the .user or .suo files, leave those out.) But a team sharing the compiled binaries will run into headaches. Binaries in general are fine, such as for example referenced DLLs. Just not the code's intended built binaries.

Basically, commit everything you need (and only what you need, at least within the scope of the project's code hierarchy) to build a complete version of the project. But don't commit the actual built output.

David
  • 176,566
  • 33
  • 178
  • 245
  • `Just not the code's intended built binaries.`: Should these files be put in `trunk/build`? – Chris Laplante Dec 28 '10 at 01:08
  • 1
    @SimpleCoder: In a folder such as `/build/` I would intuitively expect to find scripts for building (perhaps even deploying) the project, such as NAnt or Rake files (which are, themselves, source). Maybe some other build-supporting stuff as well. But the source control hierarchy in general should not have its project's build output anywhere. What a developer gets from source control is what they need to build the project, not the built output. – David Dec 28 '10 at 01:11
  • Ok, that makes sense. Thank you for clearing that up for me. – Chris Laplante Dec 28 '10 at 01:12
3

I commit everything except:

  • the \bin directory
  • the \obj directory
  • .suo and .user files

See this question for details on that last bit.

Community
  • 1
  • 1
Robert Rossney
  • 87,288
  • 24
  • 136
  • 211
3

Do commit:

  • Source files and folders

  • Resources (XML, CSS, ini files...)

  • Non-generated binaries (images, icons, sounds..)

Don't commit:

  • Compiled files (exe, dll, jar)

  • Generated source files

  • Machine configuration specific files, i.e. files that contain say filepaths to some local file on your computer which may be on entirely different place on my computer.

Goran Jovic
  • 9,040
  • 3
  • 40
  • 74