Source control folder anti-pattern

I ran into this issue at work today. Another team depends on my teams code to create customer specific solutions. Now they have an issue where they have to keep track of which versions are currently in use, and produce software for the different solutions. Now I have issues with keeping more than one version of working software in production. The administrative cost for this is enormous and it keeps the organization from scaling.

This is one of the problems that could arise from keeping more than one version of the same software in production. The team that creates customer adaptions have to keep references to the different versions of code.

This means that they might have to compile the same code but with two different versions of the software. Either they keep two versions of their software checked in under source-control at two different locations, or they keep two versions of the references checked in, or both.

Using source-control in this way defeats the purpose of using source-control. You do not use the time dimension of the source control system, instead your just using it as a shared folder.

Instead the way to use source-control is to check-in the references for each version they have to support, in order. Keeping them at the same place, this enables them to get the specific version of the reference and compile a custom delivery for that specific version. That way you are working with the time dimension instead of working in parallel to it. Dependency management can become a pain in the rear if you don’t use the tools for what they are worth.