At work we have scratched SCCS and are moving to subversion. For those not in the know, this is basically a way to keep our source code somewhere safe. They basically revision control software that allow you to go back in time and view previous versions of your software.
SCCS was the very first source code revision control system ever built, back in 1972 and is considered obsolete within the industry. Subversion and GIT are the two leading source code revision control systems today, and for a variety of reasons we decided to go with subversion.
As just about everything else in technology, thing have changed rather significantly over the last 37 years. Today's systems allow you to keep track of different version of your software as well as create all sorts of different branches of your software.
With subversion I can come in to work, grab the latest copy out of "trunk" and start working on it. When I am done I put my code back into trunk and go home. If someone comes in after me and starts working on the project then they'll have the work I did, and after they leave and I come back in I get all the work they did. If someone broke something along the way it is easy to go back and pull out an earlier version. It will even tell you the different between the two files so you can see what changes caused the problems.
It is also common, during a project, to try a new direction for accomplishing a task, only to realize that it won't work. Without a good revision control system you have to make a copy somewhere on your computer and then play with that. With subversion you can stay in trunk, and if you decide against where you where headed, simply roll back. If the changes are really big you can create a new branch and have the entire history of your new direction and then decided if later you want to merge those changes back into your trunk or not. The other great part is that it will look at the difference between trunk and your branched version and automatically put only your changes in trunk.
At some point in your development you will be ready for your users to start testing and your product will go in beta. At this point you branch your code off into a beta branch. Once testing is complete you create another branch. This will usually be given a version number, such as 1.0.
As your released product goes out, it is inevitable that your users will find problems. So at that point you fix them in trunk, push them out to beta and ask your users to test those changes, and finally make a new release, probably called 1.1.
In SCCS, at least how my coworkers have been using it, you have one version, and that is your release version. When you want to make changes you get the code out of SCCS and put it on your desktop. When you are ready for testing you give the program to your customers, and once they have accepted that your changes fix their problem, you then put your modified version back into SCCS. So SCCS keeps your production version and nothing else.
So in SCCS you take the release version and work from there. In subversion you take the trunk (i.e. dev) version and work from there.
SCCS was a big advancement when it came out. Today subversion gives us a lot more power and a sane path between development, testing, and release, and a way to track it all.
We have already had problems where we where developing applications outside of our source control and unforeseen problems wiped hours, or even days and weeks of work, which we couldn't recover because the development code only existed on a hard drive somewhere.
We have also ran into issues where we had a need to dip back into old code we weren't using anymore to see how we did things in days of yonder.
So you would think that with our move to subversion our team would be excited about the ability to merge and branch and keep track of our whole development cycle, given the issues we've seen in the past.
Our complete codebase is in the process of being rewritten, and heading off this new direction is someone who, until recently, had been working outside our group. His name is Nelson. He came in to our group once he had the base of the system mostly built and ready for our input. He is just a little older than myself and is more technologically in line with my way of thinking than that my other coworkers.
When it came down to have a meeting about how we are going to use subversion Nelson started to lay out how to use it and everyone else just about flipped. They had never seen anything like it before and it was way outside of what they know and love. They immediately rejected it and started drawing up plans for how we can use subversion like SCCS. Their solution is basically to put the released code into trunk and we work out of there.
Nelson and I argued until we where both blue in the face. Mike kept calling out, "This is the way we've always done it." Eventually I called him out on it, pointing out that that is usually a key indicator that it is time to change.
Despite my explanation above, I don't fully understand how to use subversion. Because I am a junkie for open source development, I read blogs from lots of developers that use subversion for their products, and I occasionally pull code from their trunk and compile it. So I've used it a little and am only vaguely familiar with the details on using. This is one of the reasons I was so excited about using it, until I found out that just wasn't what everyone else had in mind.
As I listened to Nelson explain it in our first meeting I started understanding what people where talking about in their software development blogs. So I was doing a very poor job articulating its power while trying to get everyone else to see the light. I started pointing out that everyone else uses subversion this way. Nobody called me out on it, but I realised that "everyone else does it that way" is just about as poor an excuse as "we've always done it that way."
Eventually Nelson decided that he would no longer discuss the issue as it "makes my blood boil." However, occasionally he can't help but to get going and pour his heart out.
Talking to my brother, and a few other people who work in the software industry, my fight is not new. It appears that the older generation of programmers just don't get it. Here I am, with hardly a year under my belt telling a group of people with 10+ years of experience that they are all wrong and need to listen to me. Not just telling them, but having very heated debates about why I think they are wrong.
So as of yesterday our code is loaded up into a subversion repository with our "release" code sitting in "trunk." I don't know how to articulate in a non-condescending way how absolutely asinine this is. I even made a plea to, if nothing else, don't call it trunk. Just call it release or production. I know it is just an issue of semantics, but I don't report to type with my toes, so we shouldn't report our production code to be trunk.
Another part that bothers about this is my career growth. If I go to interview for a job, and I am asked about revision control I want to sound competent. I'd like to be able to explain in great detail how it all works. I don't want to sound like I either came from cave man days of programming, or that I think I should be wearing my cap on my captains quarters.
Fortunately there is a light off in the distance. As I mentioned earlier Nelson has been building the basis for our new system. It will be a fazed complete rewrite. He has already started putting his code in a completely different subversion repository using the proper method of trunk, beta, releases and branches. As our old system is slowly merged into the new system, it will all have to go in the proper way using the proper methods, and eventually this nonsense my coworkers have concocted will go away, and I will ultimately be the victor.
I am also positioning myself so that my primary work will be doing the interface designs in the new system, so hopefully the majority of my work will not reside in the old system anyhow.
No comments:
Post a Comment