SVN prevents doing proper code reviews

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.

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.

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.

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.