- Wiegand.DK - https://www.wiegand.dk/wordpress -

Source repository / Libraries / Reusability

Source repository / Libraries / Reusability

The first thing you have to do is to provide an enterprise platform that your developers can have en common. This is a simple thing as where do they put there source code? And where do they publish libraries that they haven in common?

The first thing that needs to be installed is a common source repository. There have been many over the years and names like CVS, Subversion, GIT, MS SourceSafe, ClearCase, etc properly sounds familiar.

I have over the year worked with most of them and most of them actually work ok. The most important thing is that the developers have a common place to put their stuff and that the place doesn’t fuck is up for them.

One of the buzzwords regarding repositories is refactoring. That it is possible refactor code along the way when the business and the developers by time are more clear of what the actually are doing. A nice thing regarding refactoring is that if a file should change its name it still remember the old name and therefore can present the complete history. Some of the older repositories are not very good at this and when multiple developers work at the same code it can really turn into a mess. Been there, done it – and it was NOT fun.

If your have the choice don’t limit yourself by choosing an old repository. Some of the older repositories don’t handle refactoring well and some of them even don’t handle multiple users well. By this account it is not advised to choose CVS, MS SourceSafe and ClearCase. MS SourceSafe just doesn’t work and thankfully Microsoft has dropped it. The same is the case for ClearCase – it is VERY heavy to use and is a giant from the past. CVS is one of the better older systems but it doesn’t handle refactoring well.

The main battle is between Subversion and GIT. GIT is the offspring of the open source community and is the perfect choice if you are doing and open source project where you don’t want a main repository server. Subversion is more the old school with a central repository server that everyone has to use.

If you are doing an internal enterprise project Subversion is the easiest to use and very easy to setup. Wandisco have a freeware server edition that is most recommended called uberSVN –  http://www.wandisco.com/ubersvn/download [1] . It will get you up and running in no time.

If you are doing an open source project you should look into Github ( https://github.com [2] ) for a start. It is pretty strait forward.

Another thing is where to place your common libraries? Your will off cause place the source code in Subversion or GIT, but what about the compiled libraries? Maven and their repository thought have solved the problem very well. Today a Maven repository is not just accessed by Maven client but also by a lot of other frameworks that need a common way of handling dependencies. This means that you can publish into a Maven repository with a framework of your choice and extract it yet with another framework of your choice – that is neat and every developer doesn’t have to use the same framework.

There are some Maven repositories out there and the main 3 are: Apache Archiva, Artifactory and Nexus. I haven’t worked with Archiva but only Artifactory and Nexus. My opinion is that Nexus is far the easiest to use and maintain but Artifactory can be used as well.

Conclusion

My recommendation is for an internal development department with both consultants and internals to use Subversion as source repository and Nexus as dependency repository. They are both very easy to install and there are a lot of good tooling available. I have used Nexus for the last two years (Artifactory in the five years before that) and Subversion for the last seven years. The teams I have been running have worked well and there have only been minor problems along the way.