For the past 8 years, all Dev4Press plugins, themes and other projects were managed through the SVN repositories. And, now Dev4Press has switched to Git. Here is why, where and how.
There are many debates about Git vs SVN, and you can make pros and cons list for each version control system, but the fact is that in recent years Git is gaining in popularity thanks to GitHub (and other new Git oriented hosting solutions). But, for Dev4Press development, SVN was working very well, and there was no need to switch to Git just for the sake of using more popular version control system.
Do I really need to use Git?
I know that many Git users will tell you that Git is better for collaboration because of it’s distributed nature and that branching and merging are better. But, for me, all that was not that important: I am the only developer in Dev4Press, so I have no need for sharing repositories and collaborate with other developers. And, the way merging process working in SVN, I had no issues with the process in the 8 years I used SVN.
For each plugin, I have a repository, and I keep branches for every major version, and tags for each public release version for all plugins. It often happens that I work in the trunk on new major version, and also fixing current major version in its branch and moving these changes from branch to trunk always work OK.
So, when it comes to major Git vs SVN features, SVN is working great and I have no complaints on the workflow or features and I need and use.
Why the switch to Git?
There was only one reason I have decided to move from SVN to Git: problems with SQLite used in SVN on Windows. And this is not the new problem, it exists in various forms for many years, and it got much worse in Windows 10, with no permanent fix available.
Yeah, it sounds strange, but the way SVN uses SQLite under Windows was creating massive problems for me in the past 7 or 8 months. If I wanted to update local SVN repositories, nearly 80% of Update and Commit operations end up in SQLite database locked errors. And these errors effectively lock up the repository that can be resolved only by running Cleanup. And sometimes, after cleanup, same SQLite errors appear again. In extreme cases, it can take 5 or 6 cleanups and attempts to Update for the process to finish correctly and without errors. There are days when I wasted more than few hours to update local repositories on different local development setups, and the problem was so frustrating, that I finally decided to try something else.
After a lot of testing, I have found that problem is specific to Windows 10 (64bit), and when working on my older Windows 7 (64bit) computer or test Linux machine, there were no SQLite issues. I am using Windows for a long time now, and the only reason to use Linux in development is testing. I don’t like Linux and I don’t like MacOS, and it was not a good solution for me to change operating system and change my work process completely just because of the SVN issue. Having versioning system is essential, but if SVN can’t fix the SQLite issue for years now, it is easier to switch to something else.
Where to host Git repositories?
After I have decided to move to Git, the main issue became where to host the repositories. I have evaluated many Git based hosting companies, and as you may imagine, GitHub offers the most features and much more than just the Git hosting. But, again, do I really need all that? I just need a reliable hosting for Git repositories, fast and highest possible availability.
So, after few months of testing and evaluating, I decided to go with Amazon AWS CodeCommit. I already use Amazon AWS for a lot of things (including CloudFront and S3), and CodeCommit was a logical step for reliable Git hosting without any additional features that other services may offer. And, this way the billing stays under the one AWS account. But, the surprise here was that CodeCommit is essentially free for unlimited repositories and up to 5 users and 50GB storage.
How to transfer from SVN to Git?
Well, there are so many tools and tutorials on how to transfer complete SVN repository and it’s history to Git. But, after I did few tests, this was not working for me. SVN has a way for adding external repository inside any other repository, and transferring that to Git was not working at all. Git has submodules, but they are not the same thing, and the automatic transfer was not possible, and all my repositories have at least one external repository used.
So, I decided not to convert complete history at all. I am now running local SVN server where I have all old full repositories with complete histories, and if I need something old from any of them, I can access legacy SVN server and check it out. New Git repositories are starting with the current versions of all plugins, and I have manually created each one, added submodules for shared code libraries and more. Currently, I have 60 Git repositories and for all plugins and various other libraries and projects. And, I am using SSH with RSA key to work with the CodeCommit.
Git experience
I will miss SVN, it was a very important element in my development work for 8 years, and it has greatly improved my development processes.
So far, the switch to Git and using Git in daily work has been very positive. I am using TortoiseGit and SourceTree and NetBeans also supports Git. I am working with Git for a full week now, and I had no problems, and my adjustment to Git was faster then I thought it will be.
