First of all, I should point out I actually like GIT. That’s important to state as this article may seem very negative. What follows is a semi-rant about how GIT evangelists can be brainwashed into seeing nothing wrong with GIT and believe SVN is the devil, and how it probably just is much easier to stick with SVN.
For years I have worked with companies who use SVN for source control. I also use SVN personally for source control at home. It works really well, and you can set up an SVN server in less than 5 minutes on Windows using VisualSVN or in less than 15 minutes on Linux using Apache and dav_svn.
The project I work on has hit a slight road-block however. There is a third-party team of contractor developers that work off-site. Recent changes to the company security policy mean these developers no longer have direct access to the SVN server any more (all source code is now ring-fenced behind a non-web-facing network). So for months we have been forced to do a really bad practice of taking changes from them via a zip file transferred via SFTP and then an internal developer (usually me) applies that zip of patches to my local copy and commits to the repo. This is bad in so many ways – we don’t get an accurate change history, and the developer/I don’t know the full details of all their changes to correct conflicts without sifting through all their closed tickets so there is a strong possibility of introducing bugs.
So what can be done to fix the problem? Well I came up with the idea of putting a GIT server in the mix. The company utilises cloud services from Amazon and I suggested we put a GIT server that both our developers and the third party developers could connect to inside a secure Amazon EC2 network. The company’s security teams have approved EC2 use and I saw it as a good way to keep our code safe and also allow a common place for both the third party team and internal developers a way to share code with full change history.
At this point you may ask;
- Why don’t you just use GitHub
- Why don’t you use Amazon CodeCommit
The answer to both these questions is quite simple:- neither service has been approved by the internal Security team as suitably secure. Generally, enterprise-level businesses are super-paranoid, and you can’t do anything without sign-off from security. The security team’s justification for both denials is that both these platforms are shared environments.
Their definition of a shared environment is where data is being stored in such a way that it could potentially be accessible by a third party through error or malicious intent.
The internal security team is only happy when a third-party platform can guarantee that there is complete separation between your data and another’s, preferably by being on different physical hosts.
So back to the topic at hand – GIT. My experience with GIT so far has only ever been with GitHub and using GIT-to-SVN bridges. I have never tried to set up a GIT server myself, and this is the point where the evangelists begin belly laughing and saying something along the lines of ‘Silly David! You don’t use GIT servers! Every user is a server!’ (someone actually said that to me). To which I point out again what the plan was – to have a server in EC2 hosting GIT; not me – a server.
That middle man step is important. My desktop machine is only marginally less isolated from the outside world than the internal company SVN server. I can browse the web and push up and pull down files, but there is no way in hell my desktop can map services out to the public web.
Setting up Git on Linux and migrating an SVN repo to GIT is quite frankly a tooth ache. The documentation online is absolute rubbish and it is not an experience I really want to do again. If you follow any guides available under the search phrase of “migrate svn to git”, you often get guides that basically tell you from a context of your local machine only. They do not explain how to use a server – and if they do reference servers then they just assume you’re using GitHub. The documentation found online is a mix of platforms – some tell you only steps for Linux, some don’t fully explain the steps, and some just don’t consider real-world use cases beyond hobbyist programming.
Even though a server is really just another personal instance of GIT on a dedicated machine (something that no guide I’ve seen explained clearly), I needed to know what the steps were to setting up remote access for others to push and pull from.
Linux can be very restrictive in that respect with user/group file permissions. Most guides didn’t even answer basic questions like: Are there any firewall ports that need opening, do the repos need to live in a certain file system location, what on earth are the URL formats used to connect to the remote server? – that sort of thing.
The best guides I absolutely love (sarcastic tones needed) on migrating SVN to GIT are the ones that tell you to use ‘svn2git’. Yes, in the end ‘svn2git’ made my job easier – but I had to install Ruby and RubyGems (- which can be difficult under restrictive security policies in organisations), and then automatic gem downloading is of course blocked by the corporate security policies. As there is no easily available download point for gems online (as Ruby just assume you can reach the packages using the gem installer); I then had do go for a coffee break, download the gem from the free wifi in the coffee shop in order to then bring it back to the office and install it… just to convert the bloody SVN repo to GIT.
At this point I think I’ve lost the plot. What was my goal again? Collaboration with an external team using GIT hosted in a secure virtual cloud. That was the goal. And where am I with that? I have a GIT server in the cloud. It’s secure. I can push to/pull from it. It contains a clone of the SVN repo now. I still have an issue regarding CI. Our CI server lives internally along beside the existing SVN server. So somehow changes in the cloud GIT need to get back to the local network to commit for the CI server to pick up. That’s the next challenge… I’m thinking of solving that using an SVN-to-GIT bridge. I’ll give it a go and write up another post in the near future.
The conclusion of all this was I thought GIT would be an easy choice. I have friends who program and colleagues new and old who are passionate about GIT. I know people obsess about how you don’t need to rely on central servers with the system but in reality, in big corporate environments you do. Enterprise Security can greatly affect your abilities to implement solutions, and it’s what keeps things like SVN going – because they work well in enterprise environments.