The proper aproach of Subversion when using DLL

build-systemdllprogramming practicessvn

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?

Best Answer

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.

Related Topic