There comes a point in any developer’s life where he/she must work with one or more people on the same project. What’s the correct procedure? How is this done? There are a number of different ways. Some good, some bad.
The Bad: You may have a method in place where only one person can be working on a file at one time. You have to notify the other developers that the file is free when you’re done with it. They download the latest copy every time and so do you so as to not overwrite the work that was just completed.
Some of you may say “Well, why is this bad? We’ve done this for months! It’s worked out pretty well so far!” There are a number of different answers to this question, which I’m going to deal with right now.
This is a bad method because time is money and this method is much, much slower. What is a programmer to do while he or she is waiting for the file to be free for editing? Read blogs?
Time is money.
If the company had source control, both programmers could essentially be working on the same file at the same time. I say essentially because technically they both have their own versions of it and the source control program (Subversion is the one I would like to write about today) will merge their changes together intelligently. Oh wait, this isn’t good. Now you won’t have time to read my blog because you’ll be working!
The second reason the “one person, one file, one time” method is bad is because it’s extremely risky for accidentally deleting work and wasting hours of productivity. As a developer, you should be constantly using and building work methods that prevent failure at any level you are involved with.
How would you feel if you worked on a function for two hours, then because someone overwrote the file with their copy all your work was lost? The reverse is also true: How would you feel if when you saved your work you accidentally overwrote a day’s worth of work and changes?
Time is money. Again.
“But before you save your file you can make a backup of the original file!” I hear you saying, way in the back. Of course you could, but how far do you want to take that methodology? Will you remember every time? Will everyone who works on the project remember, every time? What if it’s a one-line fix? “Oh, I’ll just log in quickly and fix that typo.” and the like are sentences that run shivers down my spine when thinking about using this method.
So the person logs in and fixes the typo. Because it was a small fix, they never checked to see if anyone was working on the file. So now we’ve got two changes that need to be merged somehow. I’m sure that person will be wondering the next day why the typo has reappeared after you save your file!
Okay. So what’s the solution then, smarty-pants?
The good: The solution is source control. It’s not new. It’s been tested and proven multiple times in the computing industry and there are some big players that use it. There are a multitude of different kinds that do some different things, but to the layman the simplest way to look at it is to use a common source control program called Subversion. Everyone’s heard of it, a ton of people use it. Nerds of different flavors will tell you there are better ones out there, and that may be true, but Subversion works. For a lot of folks.
The concept is simple: A project is set up in the Subversion software. Two programmers “check out” (think of checking out at a grocery store) a copy of the project on their computer or development server and work completely independently.
Programmer “Jane” and “Jack” are both working on the same project. Jane is building a module not related to Jack but in a few cases they may modify the same files. That’s no cause for concern, deliberation, or communication. They happily keep on working until their particular task is complete.
Jane finishes first and “checks in” her work by “committing” her work to the Subversion server. Everything goes as planned and her work is then “committed” to the main project files. Jack finishes his work a few minutes later and attempts to check in his work. Uh-oh! Jack’s copy of the project is slightly out-of-date! No big deal, he issues the “svn update” command and all of the files Jane edited are updated on Jack’s computer. Any changes to the files that they both worked on are merged automatically.
After he has updated his copy of the project he commits his files and goes home for the day.
Wow! Sounds great. But what happens if Jack deletes parts of the source code that Jane edited?
This sort of thing is called a conflict. They’re pretty rare and in most cases you can resolve the conflict in a few minutes. When you edit a file that is marked “in conflict” by Subversion, it shows the added and removed portions. You can make adjustments based on which is correct and issue the “svn resolve” command to consider the issue resolved then commit the correct version.
Cool beans. How do I start?
First, you install Subversion on your server. Programmers will connect to this machine, “check out” a copy of the project, and begin work. In most cases, installing Subversion takes less than 10 minutes. You should check with your particular Operating System documentation to see how to install Subversion, but in Mandriva Linux you can do it through the command-line with this command (logged in as root):
# urpmi subversion
After installing Subversion, you will need to pick a spot on your hard drive where you want your project files to be located. For me, that’s almost always /home/svn. Change directory to your project directory and type:
# svnadmin create <projectname>
This will create a directory and place the important Subversion bits inside it for this all to function. Make sure the directory (and all subdirectories) are writeable by the group of users that will be working on the project by first first changing the ownership to a particular user and group with this command (run as root):
# chown -R user:devgroup <projectname>
This command makes the project directory and any directory inside of it owned by user and associated with the devgroup group. After this you will need to set the permissions on the directory so that the devgroup has read, write, and execute access to this directory. We do that by executing this command (run as root):
# chmod -R 775 <projectname>
Great! Our project is ready to roll. Note that this assumes you have ssh enabled on this server (very likely by in Linux, FreeBSD, and in fact most others *nix variants).
Next, we’ll need to check out a copy of our project. Stay tuned for that tutorial, coming soon!