Tag: Version Control

If you are used to the Subversion way of doing things, branches tend to have more or less the same content/code, obviously with a few changes as the development progresses.

But in Git one can store content that is completely different from the content in a branch.

Now you might wonder why one would want to do that. But I guess there are some reasons for it. For example, I believe the Git repository itself has a TODO branch that allows developers to keep notes on what needs to be done in the future, but does not contain code. That way notes are versioned as well.

The thing about Git is that it allows for easy setup of such not-ordinary uses of a version control system — I think that is what gives it “more legs” over other DVCSs. And why one should look at using Git over other DVCS systems.

Have a look at this screencast that takes one through how to create such branches — also referred to as “empty branches” because one creates an empty branch, and then fills it with other content that does not relate to the master branch.

But if you want to create a branch like that, you can use the following code that I found buried in one of the comments on the screencast.

git symbolic-ref HEAD refs/heads/newbranch
rm .git/index
git clean -fdx
<<<< do your work >>>>
git add your files
git commit -m 'Initial commit'

Just gotta love Git.

A couple of weeks back I presented at CFObjective ANZ in Melbourne, on how to make ColdFusion development a little more cooler using a decentralized version control system (DVCS) like Git.

The basic idea behind the presentation was this:

A commonly used version control system in the ColdFusion community is Subversion — a centralized system that relies on being connected to a central server. The next generation version control systems are decentralized, in that version control tasks do not rely on a central server.

Decentralized version control systems are more efficient and offer a more practical way of software development.

In this session, I covered considerations in moving from Subversion to Git, a decentralized version control system. And also the pros and cons of each.

Version control is often used in conjunction with a testing framework and continuous integration. I wanted to demo an example of how to integrate Git with a testing framework, MXUnit, and a continuous integration server, Hudson. But ran out of time. So maybe that is something I can do another time in another conference!

You can download a PDF it here: Make it Cooler – Using Decentralized Version Control

Or view it at SlideShare.

Would like to hear from you on what you think of it.

This is sort of a follow-up on an earlier post that I had made: Life after Subversion.

I’ve been toying with the idea of moving from Subversion (a centralized version control system) to a Distributed Version Control System (DCVS) like Git, Mercurial or Bazaar for about 6 months. I played with Mercurial and Bazaar earlier this year and found that moving our development from Subversion to Mercurial or Bazaar was was a fairly significant change.

Over the last few weeks I’ve been looking again at Git. Obviously there are lots of advantages of using distributed version control system. However, what I found was that there are quite a few issues that I had to consider before making the jump from Subversion.

Before I talk about these considerations, here what what Wikipedia defines a DCVS is:

distributed revision control takes a peer-to-peer approach, as opposed to the client-server approach of centralized systems. Rather than a single, central repository with which clients synchronize, each peer’s working copy of the codebase is a bona fide repository. Synchronization is conducted by exchanging changesets, which define unique versions of every file, from peer to peer.

So here are the factors that I had to consider when thinking of moving to a distributed version control system.

IDE Support

I (and the team I work with) primarily use Eclipse for ColdFusion and Java development. There is excellent support for Subversion in Eclipse through two plugins, Subclipse and Subversive. My team mates who use Windows also use the TortoiseSVN extension.

Git lists an Eclipse-based plugin on its website. However, it is still in early stages of development. Mercurial has recently launched version 1 of its Eclipse-based plugin so that is a big brownie point for Mercurial.

But the point here being… IDE support for decentralized systems is still in it early stages.

The primary interface to work with a DCVS is command line. Now I know that developers should be comfortable with using command line. However, there are different types of developers. Also, at times development teams comprise of non-developer individuals like designers, coders, project managers, etc. To expect everyone to start using command line does not work out too well in a team situation.

Learning Curve

Obviously the team has to get used to a new way of working with version control. And there is a considerable learning curve there. The larger and more diffused the team, the more of an issue this becomes.

Repository Hosting Infrastructure

Most distributed version control systems are *nix friendly. Although they have some form of Windows-based port, but those tend to be much slower than their *nix siblings. So if you are a development team that primarily uses Windows, you need to either live with the relatively slower performance of the version control system, or start looking at using Linux (which is a big jump for many in terms of skill sets etc.)

Integration with other Systems

In my current Subversion-based setup, there are other systems that are tied into version control. These include systems to create automated builds, repository viewers and code review systems. Moving to a DCVS would involve investing resources in upgrading these ancilliary systems as well. I’m not sure if there is an easy way hook these systems into a DCVS.

So in the end…

At this point, the time and resources required in moving to DCVS is a major issue. And that proves to be a too large an issue compared to the advantages that a DCVS offers — at least for the the team I work with and type of work we do.

On the whole, the longer you’ve been using Subversion (or any other centralized system) — and consequently the more team members are used to it and the more you have other systems hooked into it — the harder it will be to make the jump.