Merlin’s weekly podcast with Dan Benjamin. We talk about creativity, independence, and making things you love.
Getting into Version Control
Jamie Phelps | Jan 4 2008
Short Version:I think it's high time I got my act together and started using version control for my web design and programming work. Two questions I'd like you to answer: How do you/should I go about making version control part of my working process? and What is a good version control system for my needs? (I have been overwhelmed by all the strangeties of SVN in the past.) The first question is the most important for me as I can pretty much adjust to most anything. Longer version after the jump... Long Version:Here's the thing. Many of you know that I'm a web designer. What I'm here to admit today is that heretofore I have not been using a version control system. I have some new projects about to start up as well as some pretty ambitious programming projects that I'll be working on over the next semester and in my last year of school working on a big group project. So, I thought now would be a great time to get my act together with version control. My work obviously requires that I do a fair amount with binary files such as images and occasionally sound. So, any version control system would need to handle that stuff gracefully. I'd also like for whatever system to integrate in some capacity with Finder. I'm not averse to the command line, but switching to Terminal to do version control operations is one more step that I fear might keep me from actually using it. I have my hosting account with Dreamhost, which offers ootb SVN repositories, so that might be the simplest solution. Also, and help with workflow issues such as dealing with multiple projects (multiple repositories or one repository with multiple projects?) is greatly appreciated. As a way of sort of getting into my head with this stuff, it might help if I describe my modus operandi for a project. All of my project folders get treated like a "document" and shoved into my catch-all "~/Documents/trunk" folder and organized by color label. (See also my blog post about organizing my files. Most of my web design projects consist of a simple top level directory with three sub directories for images, javascript, and stylesheets. In the past, if I was going to get experimental with a particular aspect, I'd just make a _bak copy of the file in question and go to work. Not too sophisticated. My programming projects go into ~/Code/$languagename/$projectname, so for my class programming assignments, ~/Code/Java/ProjectName. Again, nothing to earth-shattering. But I did want to show that I do keep my projects separated more than just by project. Maybe I should be keeping my web design projects in ~/Sites. Ach, but I digress... Finally, I think I have been overwhelmed by the alien concepts in SVN. Branches? Tags? Trunk? WTF? So, perhaps a simpler system is in order. I know Git, Mercurial, and Bazaar are the cool new kids, but is there something else out there that I'm not considering? Thanks in advance as always for your help, 43F Hive Mind. 53 Comments
POSTED IN:
 Go distributedSubmitted by PaulS on January 4, 2008 - 6:56pm.
The things (I hope) that are hanging you up on SVN are most likely to be getting a repository together and starting up new projects. I've done it a few times and it's never seemed quite as simple as it should be, especially if you want network access. After that it's all quite simple. 'svn update' gets the latest version, 'svn commit' puts what you've been working on back in the repository. DO NOT bother with RCS, CVS or (god forbid) SCCS. They're ancient and not worth the trouble. Biggest problem is that they don't save the state across the project; they save the state of each file. So, if you've got a HTML and a CSS file and you've done several checkins on each in the last week. Now you want to go back in time. With CVS the files are independent, so you have to work out the revision of each file that you want to go back to. In SVN (and later VCSs) each revision is a point in time of the whole tree. Much easier and better. I think there's a better way than SVN though. Certainly don't use time machine. It's a backup solution not a version control system. I don't take kindly to revisions disappearing out of my history, or all my revisions being broken because they where snapshotted while I was working. Time machine will do both. I would say, use a distributed VCS. Something like Mercurial (hg), git or bzr. I'll use mercurial for my examples, as it's the one I use, but the ideas are the same in all of them. There's a few reasons: 1) Setup is easy. A simple 'hg init' in the root of your tree, 'hg add' your files, and 'hg commit' and your first version is under version control. Reason: There is no central repository to set-up. 2) You can commit, and view the whole history off-line. Reason: Each developer has their own copy of the repository, so everything is local. It's also not as space hungry as you'd think. 3) They're fast. Reason: Everything is local. 4) Branching is easy. Reason: Each copy of the repository is a branch. So make a copy (hg clone in mercurial) and start hacking. Merging things back together is easy too because it's an every day operation on a dVCS. 5) Releasing to a web site is easy. Simply make a new clone onto the server when you're ready to release. You can even make a few changes there (final oops fixing) and push them back to your dev box without any fuss. Because branching is easy, and there's a full repository on the web-server, making a fix on the released site, whilst working on the new version isn't a headache. You just make a clone from the web-server, do the fix, and push it back. Once that's done you can pull the changes and merge them into your development version if it makes sense. dVCSs like Mercurial, git and bzr make a lot of sense to the one-man outfit, or the small team. The flexibility is amazing. I'm not so sure they scale as well as SVN, but that's mainly because I've yet to work on a big project with them. Oops. Almost forgot to add a link to the Mercurial Book: http://hgbook.red-bean.com/hgbook.html » POSTED IN:
|
|
| EXPLORE 43Folders | THE GOOD STUFF |
