Should I add compiled binaries to my Subversion repository?

Question

I'm developing some class libraries with a distributed team. We use Subversion for our source control. One of the developers wants to commit his bin and obj directories to the repository, that has never been standard practice for me. What's the best practice? What are the pros and cons?

Answer 1

We are also excluding those files since they "pollute" in a way your changes over time. So in every commit you will have a bunch of other files changed but you will only be interested in your source code that changed and not in the compiled files.

So imagine you are trying to check what went wrong in XYZ revision and you see in the changes the following...

a.dll

b.dll

c.dll

d.cs

e.dll

... ... ...

but you are only interested probably in the source, so versioning those files other than polluting doesn't make much sense also since you cannot since what changed inside the binaries anyways..

Answer 2

We don't commit bin and obj files as they're created when you compile so there's no real need. Don't know if that's a best practice, more a personal opinion.

I suppose you can have a seperate folder for "completed dlls" or something if it's a finished version of a dll??

Answer 3

I can see why you MIGHT want to commit the bins, for example if you have different versions of an app you need to maintain that require specific versions of the DLLs. But even in that case, you could always build new bins off a tag/branch.

As for committing the obj files, I can't think of any good reason to do that..

Answer 4

My rule is that all generated files are excluded.

Answer 5

I would not add compiled libaries to source control unless you don't have the source code.

For example:

3rd Party Libraries/Controls for which I don't have the source = Go in Source Control under some kind of "Dependencies" folder.

Any libraries we write = Only the source is in the repository, never the binaries.

Answer 6

You surely shouldn't add any compiled files to the main branch. You can't compare them with the usual tools and they will slow down everything.

In version branches of releases, you could include them to have the original compiled files so there won't be a difference because the compiler changed or something like this. But you will most likely have all the binary releases stored somewhere else and Subversion is not really the right place.

Answer 7

Unless there is a good reason which you've omitted to mention, then no, don't add your bin directories to source control. I can't see any good reason to commit your obj directories.

Answer 8

Usually I never bind the bin directory to the source control system. The reason is, that it has to be automatically reproducable and so there is no value to add the generated dlls to the source control.

The same thing is with generated source files, but there is one exception: If it takes time or you have to have an infrastructure to generate the source files, then I add them to the source control.

When you want to manage different versions, the branch approach would be my favorite one.

Answer 9

I try not to store any binaries in our source control system - not even libraries where we don't have the source. Having the binaries in the repository bloats the repository and makes checkouts slow.

We use Maven to build our Subversion projects. In maven, all binaries needed by your application (but not created by your app) are stored outside subversion in what's called a Maven repository. Maven uses conventions to attach a "version" to binary files used by applications. These files are easily shared by applications and developers (1 copy for everyone).

Answer 10

The only case where I have seen that have value is in an n-tier application where some binaries are distributed from one tier to another.

For example, part of the code represents common objects used by all tiers. Then each tier is really its own sub-project that uses the common objects referenced as binaries, but working on that tier alone relies just on the binary. In that case, even though in the project as a whole the source code is there, in fact a binary is a part of the project, like a third party library in a way.

In that case it may make sense to make sure that the tier continues to compile successfully by freezing the right version of the binary in source control, and not always building from the source.

That being said, life will be a lot easier if you can void that paradigm, and include all dependencies in the build of each tier. Having the binaries of one part of the project behind the source in another is not pretty and can lead to disaster.

Answer 11

We don't commit bin or obj folders, and we used to create a new folder on the repository root called library and we put there all important dll files, such as the used third party tools, for example ajaxtoolkit, fckeditor,.... and and other dll files we see its important for this project.

Answer 12

Well, let's play devil's advocate... here's a case for storing DLL's in a repository.

Company A has 6+ teams at any given point in time. Most of these teams develop at least some part of their product in C#. Given the specific nature of Company A, the standard DateTime classes don't have enough functionality, so they have developed their own classes derived from DateTime which they make available in a DLL.

Each of the 6+ groups has its own directory in the repository and most require the DateTime DLLs, so they have a copy of the compiled DLLs in each product directory, and push new copies to a directory only when there is new functionality available that the project in that directory requires.

Is there another solution that gives the following benefits?: 1) Prevents the developers from having the check out two directories to work on a single project. (In real life there are more than two, but for the sake of this example let's call it two.) 2) Prevents QA from having to retest all products when only one product needs to change the DateTime classes.