This site is now just an archive over the rise and fall of Flash. The domain flashmagazine.com is available for sale
Login | Register
Why use a versioning system?

January 16th 2008 | Jens C Brynildsen

0 comments

 

Why use a versioning system?

Do you back up every day? Do you work all by yourself and never share your code? Do you never want to go back to a former version of a file? If all answers are yes, you probably use a versioning system. If not, read on to discover a better and professional way to work.

by Jens C. Brynildsen Ever since the dawn of computing, programmers have had a need to back up files. Initially, you'd just dump your code on some floppies, tape, CD/DVD or an external harddrive. For small projects, backing up files will take you a long way, but what happens if there is a fire? Did you follow advice and keep one copy outside the office? If so, how old was it? What if the backup is harmed in some way? If you use a code versioning system (also called revision control system or Source Code Management System), you'll never have this problem again.

Never loose code again

The implications of loosing code can be massive. Luckily there are many ways to prevent this. Professional companies already have solutions in place, but most smaller shops and developers backup on a very irregular basis. A code versioning System solves the backup issue. When a file or project is updated, the developer may send the changed file from his/her local computer to the versioning server (using the COMMIT command). By doing this, he/she will always have at least two copies of the source files. If a file is already on the server (in the REPOSITORY), the system will not overwrite the file, but rather store this as a new version of the same file.

imageIf you use a versioning system and your computer is lost in a fire, you just get a new machine, install CVS / Subversion, download the files (using the CHECKOUT-command) and you will be right back where you left off. Given that the code versioning server was not in the same burnt down building, it really is this simple.

Flex makes versioning easy

A good code versioning solution will integrate with the tools you use and become part of your workflow. Since Flex is based on the Eclipse platform, there are several solutions available and they are all free. There are two main solutions to code versioning: Concurrent Versions System (CVS) and Subversion (SVN). CVS was the original versioning system and it's widely supported. Subversion was built to fix certain problems with CVS. Personally, I prefer Subversion and I use it for all my personal projects. At work, I've used CVS for three years and that works well too. What option you choose is really up to you, but be warned - some developers have strong feelings for one or the other. Both are easy to learn so it really does not matter what you choose unless you are a "power user" with specific needs.

Code versioning also solves another major headache. When there are several developers working on the same project, code versioning makes sharing files a breeze and it ensures that you never overwrite other peoples changes.

image

Share your code and work with others

When you use a versioning system, you upload your code to a common server. If set up for that, you can access this server from anywhere in the world ensuring access to the latest files even when you are traveling. Not only that - any developer with access to the code repository can also download and contribute changes. All you need to do is to download the latest changes (using the UP command) from the CVS server before you start editing.

You may wonder what happens when two persons change the same file? This is also handled by the system. If the two programmers changed different parts of a file, the system will just merge the changes. If there has been changes to the same lines of code, the system will tell you that the file cannot be merged automatically so you will have to do it manually. Different systems differ in how this is done, but in most cases you'll get a DIFF-view that will show you exactly what is different and on what lines the differences are. A good DIFF tool can make this process pretty painless, but explaining this is beyond this articles scope.

Setting it up

Flex comes with CVS support built in, so for that there's nothing to download. If you opt for Subversion (SVN), there's a small setup but it's really not hard at all. The next thing you need is to select either CVS or Subversion and set up a server. There's several tutorials online on how to set this up for both CVS and Subversion, but I personally prefer to have someone skilled manage my servers. That way, it's not yet another thing to fix if it's broken and I don't waste my time patching, updating or fixing hardware and compatibility issues.

Up until now, I've used a service called CVSDude (note: affiliate link). They offer a CVS or Subversion setup that is hosted in three different hosting facilties across the US on clustered and replicated servers that are kept up to date by professionals. That's a lot safer than having your own server in the basement. They also have a great policy when it comes to Open Source and they give out free trial accounts as well.

What I really like about CVSDude is that you also get Trac, Bugzilla, mailing lists, DAV and secure web based access (note: this is only for Team accounts and upwards. I use a Team account with unlimited repositories). Trac is the feature I use the most. It's a fully featured Wiki that has a decent built in bug tracker. The wiki is great for documenting the project. You can give out access as you like, so you can allow your client to read the wiki as well as submit bugs to the tracking system. Your PM can get access to the project timeline and status reports. The devs have access to the whole thing. It's all quite easy to use and set up and it's helped me on several occasions. CVSDude handles all updates to the server and I've never been hacked or experienced downtime.

If your project is Open Source, you should also consider using the free hosting on Google Code. Google Code is based on Subversion, offers bug tracking and a wiki, but keep in mind that everything you put up there is open for all. You don't want to store your client files or super secret project there.

PS: If you project is Flash-related and Open Source, make sure you get it listed on OSFlash.org.

No matter if you set up your own server or use a service like Google Code or CVSDude, here is how you set it up:

Setting up CVS in Flex
Setting up Subversion in Flex 3

Setting up Subversion in Flex 4

But wait, there's more!

This is really just scratching the surface of what a versioning system can do. If you create large applications, you should learn more about "branching" and "merging". That's where the real power of a good versioning system lies. This is easiest explained using examples.

Imagine that you have a team working on a big application. Your Project Manager (PM) has promised the client a working version by the end of the month (and as usual he/she did not ask the developers for advice before making the promise). You know that you'll never manage to finish the whole project by that date, but you think of way to deliver what is already finished. The solution is branching the code in your versioning system.

imageBefore you branch, all files in CVS are referred to as being in the HEAD revision. HEAD is the stem of your "code tree". It is always there. To solve your problem, you create a BRANCH from your code.

Initially, the branch contains the complete code from HEAD, but your developers can now commit files to either the HEAD version or the BRANCH version. By splitting your development team in two, one team can create a working version for the client by removing unfinished and/or buggy features. This can often be done in a relatively short amount of time as compared to completing the full application. The other half of the team can keep working towards the longer term goal without being bothered by funny dates set up by the PM.

While the code is branched, either of the teams can MERGE features from a branch to HEAD or vice versa. In this case, the developers would complete the application and then TAG all the files in the branch at delivery time so one can see what files were used in the final application. If any bugfixes are required, they'd be done in the branch. If there were no fixes, this branch would probably just "die" as nobody would commit content to it.

Another common case for branching is if you need to have a working system while features are being added/changed. Let's say we have an e-commerce website. Our payment provider alerts us of big changes in their API just as we were doing a redesign of the shopping cart (Task A). The shopping cart is depending on a Java payment gateway (Task B). Task B requires a complete rewrite, but while it is in development, it will not be stable enough for developers to work on Task A. In this case, it could make sense to branch the code and split the development team. This way, some could work on Task A with the old Payment Gateway and then merge the files into the HEAD version when Task B is complete.

A couple more things: files are never really deleted from a versioning system so you can always bring things back. Every COMMIT is tagged with the username, so if something in your application breaks, you will know exactly who committed the problematic file. There's much more to versioning systems than this, so visit Amazon.com or Google around if you want to learn more.

Once again, here is how you set it up:

Setting up CVS in Flex
Setting up Subversion in Flex

 

Next story:
Flash Player 9 at 95%

Previous story:
And the winner is…

Get new stories first

Click to follow us on Twitter!

 

Comments

No comments for this page.

Submit a comment

Only registered members can comment. Click here to login or here to register