title: Solving our versioning and build problems
body: <p>Where I work we need to rethink the way we develop software and keep track of each released version. Do you have any suggestions to solve our problems?</p>
  
  <ol>
  <li><p>We develop on Windows in C++ using VS 2005 (and C++ Builder for some interface stuff)</p></li>
  <li><p>We use GIT but in the worse possible way imaginable. We are somewhat open to move to another source control.</p></li>
  <li><p>We have 40+ in-house developed DLL. Many of those can be updated frequently.</p></li>
  <li><p>We have a few dramatically different projects that depend on those DLL.</p></li>
  <li><p>We deliver 100+ systems a year, each of those requires custom configuration. The majority also requires custom patches. We try as much as we can to bring those patches back into the main trunk but forks are inevitable.</p></li>
  <li><p>If a few years down the road we have to update a client's system, we should be able to get back the code used for that release and all the environment parameters. We need a way to validate that this code match the binaries on the client's system. Getting back the code should be as trivial as possible and maybe with the exception of the compiler we should have everything needed to compile by doing a few simple operations.</p></li>
  <li><p>A programmer should be able to release an update for a client's system without depending on any other programmer no matter in what project (DLL) the patch is. He should be able to do it rapidly (less than 30 minutes). That make the concept of a single official release almost impossible.</p></li>
  <li><p>Exchanging code between developer working on the same project should be easy and fast.</p></li>
  <li><p>Considering our huge code base we want to limit how much a developer has to recompile when he gets a patch (sharing the binaries is a must).</p></li>
  <li><p>A developer should be able to switch from one client's system release or branch to another easily (it's common to have to work on more than one release at the same time).</p></li>
  </ol>
  
  <p>Edit:
  -We don't use makefile so far but that's something we are willing to consider. Everything is built using VS solutions.</p>