Why should I not check bin and obj folders in, in SVN

Question

This seems to be very basic question but I'm eager to know the answer. I'm using Subversion (SVN) for source control and I've been checking in all the files, but the client asked me to create a rule in SVN to avoid checking in the bin and obj folders.
Why should I not check the bin and obj folders in?

The client also asked me to keep the solution file outside the repository folder. Why is that?

Answer 1

You should not add any temporary files to SVN, they're temporary. The entire obj directory consists of files that are created during the build process and are then discarded. (sure, they stay on disk because some are re-used, like a cache, when the source files don't change but that's the only reason they're not deleted after each build).

the bin directory is a slightly different matter. It is ok to add binary files to SVN, you probably already do it for icon and image files already. Some people add the built binaries as well, that's a decision that depends on your configuration management processes, there's no 'wrong' answer. However, sometimes your bin directory can become filled with other files that you do not want to add. If you're building .net apps, you'll get a load of dependant dlls copied to the bin directory that are not strictly part of your project. Adding those will just bloat your repository for no benefit. Similarly, there are supporting binaries in bin such as .pdb debug symbol files. These aren't really needed either.

For the solution file, I'm not sure of the question but if its not to be checked in it'll be because a .sln file is just a "wrapper" for one or more project files. Its not strictly needed to build a visual studio project as a new one will be created as needed. I guess your users might create their own .sln files with different groups of projects in them, making each one different to each user. That would be a reason to prevent checkin, so each user would not overwrite each other's custom files (though there are ways for a user to prevent modification of a file that is stored in svn).

So it sounds like your configuration strategy doesn't involve adding any binaries to svn. In which case its a very good idea to prevent this from accidentally happening with a pre-commit hook. I would also recommend adding these exclusions to the client-side global-ignores to assist your users from ever trying to add these files in the first place.

Answer 2

"should not" doesn't apply to everyone. But generally:

1) Don't checkin binaries that can be generated from code.

2) SVN is a source code versioning system, and not designed with binaries in mind. Yes, SVN and other VCSs can handle binaries, but it is not their intended purpose, especially after point 1)

3) Since these are generated by your source code, they will change a lot and are not like the libraries that rarely change. Frequently changing binaries tax the VCS as any VCS cannot properly handle binaries and you tend to store more with every change to the binaries as the diffing ( delta ) is not as efficient as with source code.

Coming to the solution ( .sln ) files, it is ideal to checkin them to the repository, though not absolutely necessary. But most, if not all, .Net project are Visual Studio based and even for build purposes, having a .sln file makes the job much easier as you can call msbuild on the sln file rather than the csproj ( or other project ) files. You get other advantages like proper dependency compile, parallel compile etc.