I realize that the decision has been mostly made regarding our future in version control systems. And while I think SVN is definitely a big step in the right direction… I feel we could make an even bigger step in this direction with Git. I will admit that I am biased towards Git, I am not alone in my admiration for it. I would like to outline a few thoughts for consideration. I will support whichever direction we take, but would like to offer my own opinions and research on the matter.
-
SVN creates .svn directories in every single folder (much like CVS). Every script we write or update to our new found frameworks we use will have to handle this. We can't currently swap out a framework once it has been added to CVS for a newer version without breaking the version control for it. This will hold true for any upgrade to SVN.
-
In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to get messed up..And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal.
-
You have to tell SVN whenever you move or delete something. Git will just figure it out.
-
Ignore semantics are easier in Git. If you ignore a pattern (such as *.xcuserstate), it will be ignored for all subdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories.
-
Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.
-
CVS was released in the early 90's. Which was great at the time. SVN was released nearly a decade later as "CVS done right". Git was released around 2005 and its use has been accepted pretty rapidly and is considered one of (if not the) best version control systems available today.
There is a stigma to using Git as being hard to learn and too complicated for most applications. I personally don't agree with that at all. Most of the basic commands that our developers will be using on a daily basis are almost identical. The Xcode support for both masks all of these commands anyway and drops the learning curve almost to zero. Git really shines when you are taking advantage of the distributed model of source control. We have the opportunity to get our developers into the habit of making frequent commits and preserving application state and security. All of these can be accomplished offline. Branching and merging without the need to be connected to the central repository will speed up development time and assist productivity.
I will close with this. If we are going to spend the time and money converting our existing version control system to something more modern and up to date, wouldn't it make the most sense to bring it up to the best available system available to us? SVN has the benefit of being one of the most popular systems out there, but it also has the benefit of 10 more years in use (plus an extra 10 based on the fact it was built up from CVS). I know there will be a learning curve with either system, but I think that we will be better served going with the "latest and greatest" available to us.
If you made it this far, I thank you. Please don't take this email as a sign of disrespect. I will fully support either system we decide to go with. I just felt obligated to share my opinions on the matter before we've gone to far to turn back. Thanks.
Bill