Thanks for the feedback tjr; especially so in regards to the 'version management' suggestion. I have felt that this is likely someplace I need additional knowledge and experience. I have accessed Subversion repositories, but in truth, have never maintained my own nor would I know what to do in a instance where it was actually required.
Learning version management is on the list to learn now :)
svn co file:///home/you/myproject myproject-workingcopy
Work in the working copy as you would on any SVN project.
I spawn new branches whenever I start a new project. I've also tunneled it over SSH, HTTPS, blah blah blah, but it's boring now. Git is probably the future for big projects IMHO. (Although GOOG gets by with Perforce, which is basically SVN with some extra hooks)
Version management is a thought habit. Would you walk a tightrope without a net? Why write challenging code without one, then? Similar to automated regression testing, it's just another habit that offloads responsibilities onto the computer so that you can work on more interesting things.
If you haven't built at least a trivial application in *nix, even just something like a server for Dopewars, give it a shot. Obviously it's rare that you'd need to do it for a job, since most of the interesting protocols have good implementations, but you'll have more insight into when the standard implementation is actually a really bad idea... that is to say, rather more often than you'd think! It won't take more than an afternoon or two if you've done as well in all your CS classes as you say. (One thing you might like to do after that is go back and look at the twisting road the Subversion guys went down as they implemented their DeltaV protocol -- considering that these are old Apache developers, it's enlightening to see that they followed plenty of dead ends, too) For extra value, do it on an embedded system, with its totally different constraints. (If you have access to something like the Xilinx rig that we used for the CPU engineering class I took, so much the better -- FPGLAs can't help but become more popular as vertical markets are more automated)
There are so many opportunities out there for someone with a good grasp of both the theoretical and practical aspects... if you really like building things, you ought not to have any problem finding a job to suit you with your degree.
Thanks apathy,
I checked out Git a little while back. I definitely think that I need to learn more about both Git and SVN. From what little contact I have had with companies, SVN seems to be the most widely deployed for those on *nix platforms - that likely has something to do with the ~5yr jump that SVN has (?) though...
5 years? If you count from when FSFS became the standard (2005?) it's really more like 3 years. I think Subversion will probably remain the standard for your 'average' developer, and Git will make huge inroads into the more elite/distributed teams, since it's the default repo for the Linux kernel. I don't really see the point of learning how to use tools that other developers are unlikely to use -- CVS, SVN (which is almost identical to Perforce), and git have compelling projects which use them. Most others don't.
If you use SVN in a group, you should also use Trac, btw. It's fucking amazing. looks at Trac Hacks Holy mother of god, someone went and wrote a plugin to make Trac play nice with Git and Perforce (AMZN and GOOG use p4). Well, that's pretty sweet -- no effort required regardless of repo. And apparently they added a continuous integration dashboard, Bitten (http://bitten.edgewall.org/wiki/Documentation/index.html). I love those Edgewall guys. Makes me want to go back to workaday development... almost.
Learning version management is on the list to learn now :)
Thanks again, -Matt