18

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.

Improve this question
3

6 Answers 6

Reset to default
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).

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

If I set my trunk up with a src folder, should all this go there?
Yes, it should. The best thing to do really is to check out some open source C# projects and see how they structure their projects and what files they check in. When in doubt it's best to imitate someone you respect.
what about .suo and .user those are of no use in source control
@ScottS: That's true. There are plenty of other files you shouldn't check in, as well. "commit everything but your output files" is accurate, though.
@ScottS - True, there are some other files that shouldn't be committed.
11

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.

Improve this answer

Comments

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.

Improve this answer

1 Comment

+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"
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.

Improve this answer

2 Comments

Just not the code's intended built binaries.: Should these files be put in trunk/build?
@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.
3

I commit everything except:

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

See this question for details on that last bit.

Improve this answer

Comments

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.