Simultaneous Fork

I am developing in ActionScript 2 and ActionScript 3 at the same time. I decided to branch the project when I got a stable build. However, upon finding a bug during conversion (Flex Builder 2 rules), I had to document the change (quick note in Notepad) and go back and fix it in the AS2 codebase.

Upon a 4 hour development stint in the AS2 codebase, I found 3 bugs and fixed them in 3 different classes. I forgot to document them. Now, I’m contemplating the best way to handle a forked build in the allotted timeframe.

It seems the best thing to do is get the AS2 codebase to a working point, freeze it, and then start converting the existing AS2 codebase from that point forward to AS3. The mantra “garbage in, garbage out” seems to come into play here. Starting with an already flawed codebase seems a guarenteed failure scenario. I’ve read about a successful venture using the Subversion branch feature. They had to fork the build since they wanted to try something else, found out it wasn’t such a good idea, and removed the build without affecting the main codebase.

The key now becomes being able to successfully do a time estimate so you know when you have to freeze so you allot yourself enough time to convert the code base, test, and get it to a freezing point as well.

Anyone had experience writing in dual-languages for the same codebase before? How did you handle it?

5 Replies to “Simultaneous Fork”

  1. No, but I will be very shortly. I’ll be interested to hear how you do it. I think a freeze on our as2 code is going to be unlikely, so it’s going to get interesting.

  2. reworking the old code always seems to take more time.. from Flash 5 to Flash 7, from AS1 to AS2, AS2 to AS3, etc.. it seems like it’s faster to just start over with a clean slate then trying to kludge the old code into the new structure/syntax. .. we typically just freeze the old code base and it only gets bug fixes from that point forward.. use all that we’ve learned from the previous version to create the new codebase. and I try to make a clean break and work only in the new syntax. Going back and forth between AS1 and AS2 for example makes it too easy to make mistakes. my 2cents..

  3. I don’t have a choice; I need to showcase AS2 and AS3 versions of a project together, so the code-bases for the most part have to match exactly. Thus, taking a frozen (working) build of AS2 and converting to AS3 isn’t bad at all.

    What sucks is keeping track of changes from that point forward and keeping the builds in sync.

  4. There is no silver bullet. We are doing precisely this with Subversion, we forked an .asp to .aspx and now we are stuck having to support both for the next couple of months. They need to be identical in terms of methods, properties and output. UML has kept it sane. We’ve tagged .ASP as the lead even though it will be abandoned in a few months. Whatever we can do in ASP can be done in ASPX, but not the other way around — lowest common denominator dictates we have to do the driving from ASP for now.

  5. We are going through this at the moment, and have developed a wee tool for as2 to as3 conversion to make it easier. We are going to stick it up on osflash once we are happy with it. You can track its progress on our blog

Comments are closed.