What is the proper aproach of Subversion when using DLL

Question

Background:
Our team develops a solution and it includes a number of projects. Most of the projects are built as DLLs and those DLLs are used by the rest of the projects.

Currently we uses Subversion for our code management and I ask others to remove DLLs from Subversion because we do not need to keep the history of the DLLs. So I ask my team to update their source every morning from Subversion and build each project to get DLL with yesterday submitted changes.

Issue:
This procedure was very good in the beginning f the project. but now each project of the solution getting bigger and bigger.Also gets more time to compile. now each developer waste around 20 mins each morning for build solution in their local computer.

Now I'm thinking again to ask each developer to submit their built DLLs to Subversion at end of the day and the next morning the rest of the users can download these DLLs directly from Subversion.

But I feel something is wrong with this procedure. Because Subversion waste space keeping the history records of each DLLs. Now I'm searching for a better solution.

Do you guys have any idea over your experience?

Answer 1

You quite clearly need a dedicated team member who's job it is is to update their code to the head every time anyone commits a change, and also does a full, clean build every night and copies the dlls produced each and every time to a central location where the other team members can grab the dlls.

Unfortunately this is a laborious and tedious task.

Fortunately you can get a computer to do it for you!

They're called Continuous Integration servers and are designed to just this - grab code every commit, build it and "archive" the results somewhere. My favourite is Jenkins. It can put the resulting dlls into SVN or can copy them to a network share (I'd recommend putting only released dlls into SVN, daily or on-demand builds are too transient to keep for long). It can also email out everyone to say that a build failed (a developer forgot to add a file that was needed for example), and can also show a dashboard with the status of every build.

Answer 2

Something is wrong indeed.

There are two approaches to organize development of something split in modules:

1. Separate and asynchronous: you version every DLL separately and treat the rest of modules similarly to third-party components. In this case every DLL should make some kind of release to provide its functionality to users (other developers). This will include putting that "released" version of DLL either to source control repository or to artefact repository.
2. Combined and synchronous: all DLLs are developed together and released (when needed) together, in this case you should think about speeding up build process. This can be done similarly to optimizing a program - find the biggest slow-down factor and eliminate it.

Selection between these two approaches is usually based on degree of coupling between them. If most of changes touch several DLLs, or changes in different DLLs are usually dependent on each other, likely approach #2 is more appropriate. If every DLL has stable interface, clear and specific purpose and some kind of compatibility between versions, approach #1 may be applicable.

Answer 3

I don't think that it's a good idea to have a branch purely for executables and DLLs.

Executables and DLLs should be a by product of building master branch on the build server.

Build server will build the branch, execute tests (if any) and store compiled assemblies somewhere on the network. Whenever deployment is needed, you will take compiled artefacts from your network location and deploy them into relevant environment.

You don't want to build DLLs locally and then upload them somewhere. What if you build on a 32 bit machine and then try deploying to a 64 bit machine? Same goes for sharing compiled artefacts between developers.

At my previous job we had a problem where full build (with all the unit and integration tests) was taking just under an hour to run (assuming nothing fails, which is a risky assumption to make). Now it's not feasible for the team of 20 developers to run a build each, potentially wasting 20 hours of development time. What we've decided to do is build all the executables and DLLs on a build server and then distribute them to the team through NuGet.

Answer 4

There needs to be effectively two branches.

1. The development branch, which contains just code. As developers are expected to be able to compile the code to produce the DLL's.
2. The release branch. Which contains just the executables and DLL's.

In the middle, overnight, you can use a continuous integration server to build the latest version and commit the DLL's/Exe's etc to the release branch, and tag those items with a version/release number.

The release branch doesnt need to be SVN. but you can do so if you wish. It does mean that people can find previous revisions quickly.

My personal opinion is that any developer should be able to sit down, sync the head of the development branch, be able to compile the source, and run it. If this isnt possible, you need to make it possible. Either by fixing the project structure, or providing binary DLL's of code that developers are not expected to recompile. (library DLL's etc).