Two weeks ago, I and a couple of other developers from Tyro went to the first “Migrate to DVCS Sydney” Meetup at Atlassian’s new headquarters. Here’s my notes on the most salient points from the evening (with some editorial by me in italics) …

Talk 1 – Jonathon Creenaune from the JIRA team

• Know why you’re migrating. I’m sure he meant, and may have even said: have a business reason to change, don’t just be a cargo cult.

• Ask yourselves what DVCS can do better, how it can improve your team. E.g. If merging a stable branch and trunk is easier, how could you work differently/better?

• DVCS is not simple – developers need training.

Talk 2 – Tim Moore from the OnDemand team

• Because they’re working on a SaaS, their VCS structure is different (I assume simpler than other Atlassian products) because they only ever have one version in Production that may need maintenance.

• Feels Git solved two major problems for them:
  1. Avoiding having a broken trunk/HEAD revision
  2. Merging urgent changes from stable back to a diverged trunk

• They’ve optimised their change control process for stability.

• Suggested some good ways of learning Git are by practicing with GitHub and reading ‘Pro Git‘, a Creative Commons book.

• After migrating from Subversion to Git, tags from Subversion, which are really just branches under a directory called ‘tags’, need to be converted into real Git tags.

• He recommended moving all readers, meaning the read-only parts of the tool chain, over to Git first and then moving the writers, i.e. the developers (and release scripts?) over at the end, which has to happen all at once. Interestingly, we’ve done the opposite at Tyro: we’ve started trying out Git by moving all development of our largest project onto Git while sync’ing commits back to the existing Subversion repo that all of our tools still use. We’ve taken this approach because we want to evaluate the advantages for developers before putting the time into migrating all our tools.

• After the migration, they left the Subversion repository in place, and I think he said this was just in case some things were still pointing to it. I’d be more inclined to switch it off to find out what is still pointing to it! 🙂

• The team uses really long branch names that include the JIRA number and a basic description. Git’s bash completion integration makes this fairly practical as you only need to type the first few characters.

• They use feature branches and, when a feature is complete, they do a fast forward merge to make the completed branch essentially the new master, then push to all other branches.

Talk 3 – Charles O’Farrell from the Stash team

• For people looking to learn Git, it’s possible to use it locally and then use a bridging tool to sync your changes into Subversion, so you can check in without anyone else caring about Git.

• The main advantages of Git are easy local branches and powerful commands, e.g. the myriad of options for both searching and displaying the log

• Git’s ‘stash‘ command (different to Atlassian Stash) is basically a quick way to move workspace changes to an anonymous branch.

Q&A

I didn’t note down all the questions, but the interesting parts of the answers were…

• Part of the success of migrating to DVCS at Atlassian has been the support from the top to invest in the change.

• A few people with experience in Git were assigned as “Git Champions”: go-to people for other developers to resolve problems in the first few weeks.

• The pickaxe tool was held up as an example of something that teams will find very useful. Pickaxe is the -S option to Git’s log and diff commands and it searches for commits which either added or removed an instance of the given search string, so you can easily find the revision where that //HACK: comment was added, or identify who removed your beautiful foldLeft computation.

• There are a bunch of blogs about DVCS at blogs.atlassian.com/tag/dvcs

• Source Tree was recommended as a really good Git GUI. It’s a free, Mac-only desktop client that Atlassian acquired in October 2011.

• Someone asked about the ROI of switching and the response was to consider the ongoing cost of NOT switching to DVCS.

• When asked about the impact to the team of stuff-ups while learning how to use Git properly during the migration, the guys said one of the great things was that DVCS meant most mistakes were kept localised to the individual’s repository and had no impact on the rest of the team.

• Someone asked for feedback on the Git repository that someone had set up at their work which had all projects in the one repository and the advice was that this was most definitely not the way Git is meant to be used. From what I know, ‘repository’ in Subversion refers to a server which contains a tree that can be organised and segmented to contain many projects that have independent histories and, importantly, you can check out just a sub-tree. On the other hand, ‘repository’ in Git refers to a collection of resources (typically a project) that has a shared history, isn’t easily segmented and must be checked out as a whole. So I guess ‘repository’ for Subversion is probably closer to ‘server’ in Git and ‘repository’ in Git is closer to ‘project root’ in Subversion.

Because we practice Continuous Integration at Tyro (in the orthodox sense meaning “members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day”) I’ve always been skeptical about the advantages that DVCS can bring to our workflow. It seems to me the #1 reason everyone gives for switching to Git or Mercurial is that “easy merging makes feature branches far simpler to manage”, but feature branches are anathema to continuous integration, so where’s the pay off? I put this question to the speakers and their responses were:

• The JIRA team don’t use feature branches but have one branch for the front end teams and one for backend teams, so they can see each other’s changes without breaking each other’s domains too often.

• The tooling available in and around Git is far superior to what’s available for Subversion.

Here are the slides from Tim’s talk.

Here are the slides from Charles’ talk.

Image credit: grafitti of speed / mirror of symmetry by Shinichi Higashi