Where to start
But let’s start from the beginning. I am propagating thought "you have to know bad things to know why other things are good". So I am glad that I have practical experience with several version control systems (SVN, Git, Mercurial and Perforce) and can compare advantages and disadvantages of them. Also as my professional development experience is growing, insights to fundamental of VCS problematic are more deep. Hm, so there is first big problem which I have with SVN: it has built-in corner stones which are no longer supporting increasing quality of code base in these days. As software engineering is evolving, processes enhancing and productivity growing, it’s basically because all the stack is evolving and producing totally new (and significantly more productive) ways of software development (for example Git).
It’s in the trunk, so who cares?
One of the corner stones of productive and successful software development is IMHO doing code review. It has so many advantages compared to not doing it that is almost impossible that one developer doesn’t hear about it. From my perspective the code reviews is working best when they have support of the tools which doesn’t triggering unnecessary work for code reviewer. Also it’s working best if in the production code are only reviewed features and there is option to simply refuse unacceptable code. For having production code reviewed all the time, it’s becoming most productive that each developed feature has own publicly reachable branch in which developers can cooperate and only after all the work is finished, it’s merged to the trunk.
And here is one big problem with SVN: cost of creating of remote feature branches is unacceptably slow and working with them is so painful (and time-consuming) for both developer and code reviewer. Ok, one could argue that we have git-svn with which we can use SVN repository as a standard Git repository but there is one problem with it - it’s only for local environment. When you need your feature git-svn branch publicly shared with your college, you need to bother yourself with sharing your local directory, it doesn’t work when developers aren’t collocated and in fact on of the developer is responsible to be a “VCS server” which is not so delightful.
Bigger all in one commits
Next problem I have had, that after some time I was not commiting to repository on daily basis because I wasn’t accepting that I’ll commit to trunk unfinished work in my mind. This behaviour leads to bigger and more messing commits. This is not so big deal and can be solved pretty pleasingly with git-svn and local branches and with mitigating cooperating with SVN to minimum. Also in Git projects was becoming useful to squash commits to one before merging to master to have clear history, so big commits are in place in Git repositories as well. But it isn’t solved by default by SVN so another -1.
No presure to doing code review
There is no way (at least I don’t know of anything) how to enforce and check if code review has been done in SVN (I don’t count formal messages inside tickets that code review has been done). Because all the commits are directly in trunk (same for development branch derived from trunk) which is base for other branches, there is still possibility that some of unneeded code will be included for example to some release branch. This leads to situation that after some time the code review is not done in best possible manner and code base mess is growing as reverting commits are not so casual.
Not possible to enforce always green "trunk" build
Also SVN leads to this behaviour: When I am updating from SVN server, I am waiting for green build on CI server to update my local machine to prevent possible failed tests which my changes not causing. It’s mainly due to fact, that is impossible to have “always green build” in development branch (trunk) because all the commits are directly in that branch.
And after all this prevent doing continuous delivery in fact.
Not saying that is impossible to find tools which works in good manner for code reviews upon SVN. But there is mental problem of users of SVN to actually do code reviews because it seems as technically expensive operation and (what is worse) feeling that it’s hard to convince anyone to change his code when the code is alive and working. Or maybe I am missing some software with killer features which are mitigating pain with working with SVN, is somewhere there?
P.S. If you enjoyed reading this blog post, could you do me favor and tweet it or/and leave a comment? Thanks!