Playing nice with other kids on the block - Using Git in a Subversion environment.

Setting the stage

One of the frustrations for users that had the Git-epiphany is that long after they start to use Git, they will be locked down to environments where Subversion still lurks in the dark shadows, causing trouble, sleepless nights, and crying yourself to sleep.

• "The tool-set change needs to be taken into consideration"
• "But we have Subversion"
• "Why change something that already works?"
• "Who cares if you don't have connectivity to the repository? I'll sync when it is back up."
• "But my IDE has local history, why do I need another tool that keeps track of the entire history?"
• "I don't mind going to have a coffee while operation x-y-z is running on Subversion"
• Branching? Who needs branching?
• I don't bother entering commit messages because I like to peeve my colleagues by forcing them to go through commits with diff compares to find some changes.
• Our team don't have the time to spend it on other people's code to review that before they are OK to commit, so we just throw everything together in trunk and hope it does not break anything else.
• Revision numbers does not need to be sequential. (this one is a mess when you have a huge repo with multiple projects. revision numbers are scattered everywhere across projects)
• "We don't have the time to learn a new tool"

These are just some of the scenarios one will come across when trying to convince other developers to use a better suited, powerful set of tools (all against a DVCS of course).

Along my journey in learning Git and understanding why it is so popular, I came to understand one important thing: 

Although Git has all the bells and whistles of being a distributed version control system, the main realization is that it makes your life as a developer bearable. 

Yes, the bells and whistles of a DVCS brings all of that to the table, but it's all about helping you to achieve a goal in your development process.

Generally different parts of the development process needs different work flows. Each individual will go through a set of steps that he or she found to help getting to the end in a confident manner. When the process later includes collaboration, that cycle might need to change. When reaching the stage where you need to ensure that production deploys  go smooth, that part of the cycle might be different too.

What linear or centralized systems enable you to do is to dump code, slap more code to that code, throw it back to the central code and pray that nobody else thought like you and worked on the same code in the meantime. Everyone's code is perfect right...?

In contrast, you will be able to do the same thing using a DVCS, but you have better control over how the code should change, and when. You will be able to see what your collaborators did, without them polluting "trunk" or the mainstream code.

Choreographing the interaction

A simple use case during personal/local development

Say you want to make a change and you have 2, 3, 4 or more options. (Ok, I know in commercial development there's never time to try something different and it needs to be done 'right' the first time.)

How would you achieve this using a VCS that does not have "in-directory" branches?

"But I can check out different branches in subversion"

 You can, but the catch is that you have to be connected to the repository. And it won't be quick either. Add to that the clutter of every other developer's personal branches, if that is allowed. I know at the company I work at, we don't use branches at all, so the likeliness of personal branches are even less.
See where this is going? It's too much of a mess to try out different things using a central repository, and therefore innovation or different solutions to a problem never gets a chance to be tried out.

So with the quickness of Git's cheap local branches, you are free to try any number of solutions at the touch of a button. Say for instance you want to see the effect of 2 different implementations (performance comparison, UI options).  One can go about doing both solutions on separate branches (using a common parent commit).
If you organise your changes and commit them in a modular/atomic way, you can later on cherry-pick those commits to your final/definite solution when done, thereby keeping things separate and tidy. You don't pollute your code, and you don't pollute the code your peers need to look at.

Peer reviews

A benefit you'll gain by using a DVCS like Git is improved peer reviews. By sharing your repository with a colleague, you can only refer to a SHA1-hash if you need someone to look at your changes that you have committed to your own repo.

Several times now I wished that my colleagues just took the jump to Git so I can effectively just say "Here, get my current state from this location, and look there" and still have the comfort of mind that the main repo remains clean.

How do we do this in SVN?

"Check in so I can have a look...".

5 minutes later: "Ok, checked in". (OK, I'm exaggerating here, but you get the drift).

If what you checked in is not right, it gets reverted, again taking a lifetime to complete :)

Back on track

Ok, I went off track from the original topic.

In the end, I want to focus on using Git for personal development in a Subversion environment. I'm still struggling now and then to keep my workflow clean, but it's a lot easier than before.

Although you have the git-svn bridge, it did not work well for the scale of the project I'm a part of. Multiple modules in Subversion becomes a flipping huge task to manage manually, so after trying to work with git-svn, I went back to square 1 and checked out my modules using Subversion in the new 1.7 format (thank heavens for the sanity brought to svn's folder structure) so that all the syncing can be done by my IDE.

Whenever I need to work on a specific module, I simply 

• initialize my Git repository and 
• tell my  IDE to use Git for that particular module as long as I'm in the development phase. 
• Do whatever you do best and scratch around the code, 
• commit and merge local branches.
• Switch back to Subversion support in the IDE and sync back the changes to trunk.

It sounds like a lot of work managing code using git and Subversion, and I don't deny that it is. But in the end, using Git to keep track of your personal changes in code outruns the effort to keep on using Subversion for each commit. Time-wise, history-wise and code-wise.

It add's to your overall knowledge of what you personally worked on, and a nice graph to make it easy to see what you did and how you proceeded in making a change.

Believe me, people that have not yet seen the light are not impressed by all of this. I feel sorry for them, and I mean it.