A Beginner's Perspective on Version Control

Original Writing Date:  8/25/2011

So I know I need to use version control, and I know quite a bit about why and what kinds there are.  What I don't know and I am learning today is how to use version control.

First there are a couple of kinds of version control:

1) Centralized Version control - old style - a centralized copy of the source code exists and it gets checked out by one person at a time.  This is still the primary type of version control being used - especially in the corporate world.  Some major player of this type include Subversion and Visual Source Safe by Microsoft.

2) Distributed Version Control is a newer form where there technically is not a master copy - everyone has the full history of the source code saved locally.  There is a place where it is synchronized centrally - but everyone has a copy of everything that has ever been done to the source - so you have all the branches of code. Git and Mercurial are two examples of this sort of version control - and both of these are open source.


What I know is that version control is only as good as it as used.  What I don't know is when or how to check things out, when I should check things back in  - how often and why should I re-synch with a non-local copy.  And that is just my stepping off point.

When should I check things out?  So we started out the other day by pulling a full copy of the source onto my local machine.  By the way, we are using Mercurial with BitBucket as the master host.  I have yet to actually resync my work.  As a development team, we have not had to merge our code - Matthew has been the primary developer of the project I'm starting with and he uses other tools at all of his other employers.  So some of what I may say will be modified as we learn the ins and outs of multi-developer processes.  I also know that I need to pull current code regularly and that depends on how much development on the project.  I may not need it every day if no is making changes.  But with the 2 of us in this line of code, we estimate that daily or every other day is what I should expect to need.  And specifically, before I think I need to push up my changes, I need to pull down, merge the current branches and test my code against those prior to my upload.

So that's that... but how how often will I need to push up my changes.  That also will depend on how much I actually accomplish.  Right now, I'm working on an area that is relatively segregated from the application and is not a dependency for anything else.  So I can take my time.  If I were working on a part of the project that was interdependent with Matthew's work, I would need to do this more frequently.
 
One of the great things about distributed version control is that you can do micro check-ins of your source that is only visible to you.  So you can test as much as you want before syncing it to a public repository. The local check-in allows for regular fall back positions for small discrete changes.  The sync to the master repository allows others to test their code against what you are creating.

I've been recommended to read Joel Spolsky's site:  www.hginit.com.
____

Updated on 8/31

So I've been using version control for about 6 days and the first thing is that it is super easy!  Because I'm using both my laptop and my desktop to work, I'm having to save my changes up to the remote host daily and I'm pulling changes down constantly.  I'm sure that when I'm working on projects where Matthew is working at the same time, it will be more complicated, but for now, it is a quick and simple step that allows me to switch machines simply and easily.