So, A short recap,
Problems with SVN:
- Its not easy to work on multiple streams of work. SVN is not build for that.
- No offline commits. No private commits (commits that only I can see and make them public when I want). There is no way in which I can commit and not make those changes publicly available.
How did we get around those problems using GIT over SVN:
There was no way that our team could have moved to pure GIT. Other teams working on the same projects where using SVN repository for their commits. We had to work on the SVN repository for sure. Hence, we decided to use GIT over SVN. SVN will still be our central repository. All updates were taken from and commits were made to the same central SVN repository.
GIT has excellent support for SVN repositories. We use the git svn command. Heres how it helped us.
We started of with a small team moving towards using GIT. Out of 120 developers 10 developers started using GIT. In the first week, boy we had a tough time convincing people to give GIT a fare chance.
The process of unlearning SVN is a little difficult. One has to be really diligent and patient at least for a week. After that, trust me on this, you will never want to work with anything else.
Moving on, the situation of the continuous integration server was still the same. Narrow commit windows and long build times.
Lets say, Deep and Jamie are in the middle of developing Feature - 1. They have been committing to their local GIT repository as often as they want. At every logical point (the point at which all their tests are passing and code is in a good shape) they do a local commit. This commit is only visible to them and not to anyone else.
Lets say, the build goes green. They, don't need to hastily push their changes to SVN any more. If their Feature - 1 development is not complete, they don't need to push their changes to SVN. Even without pushing to SVN, they are getting all the benefits of a Version Control system.
For e.g. they made 7 local commits for getting the feature done. This means they have 7 commits in their local GIT repository, but SVN does not know anything about them. They have got the benefit of version control even without making their changes public.
When they decide the feature is read to go public they have the following options (based on the situation of build)
- Push their changes to SVN, if build is green
- Not push their changes to SVN, if build is red
If they get a chance to push to SVN, they are pretty confident that their changes are in a good state and build will go green with their changes.
If they do not get a chance to commit to SVN, they can continue development of Feature - 2 on a different local branch!
Eventually when the build goes green after n hours (where n > 1), they can quickly switch to the Feature - 1 branch and commit only Feature - 1 changes. In this situation they are confident that only and only Feature - 1 changes will be committed! That is exactly they wanted!
After pushing the Feature - 1 changes to SVN they can switch back to Feature - 2 local branch and then continue development from where they left! Awesome isn't!
Working with multiple streams of work is pretty natural with GIT.
Over and above everything else, they could commit at every logical point. This is really important!
The advantage of doing this is, one could go back in time and have a look at how the file A.java looked at logical point - 2.
When they were using only SVN, this was never possible. They could only see the entire Feature - 1 change set as one big fat commit. They could never go back in time and see how the file A.java had evolved while Feature - 1 was being developed.
We seen so far, only two main advantages of using GIT even with SVN. This is just the tip of the ice burg. GIT is pretty awesome!
But, the flip side is you need to be patient till you unlearn SVN and feel the power of GIT.
Give GIT a fare chance and you will do things you thought were impossible thus far! Do not wait any more, Go GIT it!