Before thinking that svn is too complex, I would advise you to have a look at the book “Pragmatic version control: Using SubVersion” from the Pragmatic Programmers.

It gives an easy introduction to svn, and also shows you that tags and branches are your friends :-)

http://www.amazon.com/Pragmatic-Version-Control-Subversion-Starter/dp/0977616657/ref=pdbbssr_1?ie=UTF8&s=books&qid=1199470124&sr=8-1

Subversion isn’t really that complex, especially if you have a gui tool for managing it.

You can start out ignoring tags and branches, and just use it for versioning and potential recovery.

You may find, as I do, that tags are very useful (i.e.: code as I released it on Jan 6th to the public). As a single person you may never need a branch. It depends.

Sure, SVN supports features that scare you, but you can also use it just to keep a series of snapshots of everything you’ve been doing. No need to branch or tag if you don’t want to. But if it has to not puke on binaries, has to integrate with Finder, has to come free with Dreamhost… you’re heading for SVN.

How to integrate it into your workflow? When you’re at a point you want to take a snapshot of (whether that’s the end of the day, the client wants something sent over, you’re ready to start experimenting, whatever), you just commit what you’ve got to the repository. With Finder integration, that’s a right click somewhere in your folder and a “commit changes”, type a comment (optional), and you’re ready to move forward. It’s a small change to your current setup.

One caution: moving/renaming folders in SVN can be a nightmare the first few times you do it. I’d suggest settling on your /language/project vs. /client/project vs. /project hierarchies before putting your projects in your repository. (And you only need one personal repository, no matter how many projects you have.)

You should check out Eric Sink’s Source Control HOWTO information at http://www.ericsink.com/scm/source_control.html

The guy who created Billable has a fairly good introduction to Subversion screencast that is free to download. It speaks in a very non-technical tone (including the obligatory Ernie & Bert reference) and made things fairly clear to my right-brain self. Hope that helps. -B

http://blog.clickablebliss.com/2006/04/26/introduction-to-subversion-screencast/

I know you mentioned Bazaar so I guess you’ve looked at it to some extent already. I just wanted to add a comment to suggest taking a serious look at it. My team (web developers) used it for over a year and have been really impressed.

Despite being command line only (well almost) the commands are very simple and we found it very easy to adapt to. It added almost no overhead to our process. We even had a lot of success using it downstream of of CVS (who likes working with CVS, really?)

One of the guys on my team, Stuart, has written some interesting beginner posts about Bazaar which provide a really useful introduction - http://muffinresearch.co.uk/.

Bazaar also integrates with Launchpad, a web based system which provides a way to publish branches publicly and has a number of integrated tools including bug tracking.

Bazaar has just reached version 1 so can reasonably be considered stable. We encountered very few issues in earlier versions.

If you just need to keep track of YOUR OWN revisions (i.e., you don't care so much about distributed collaboration), you really should look into using the old-fashioned starter of it all: RCS

RCS is included with every UNIX distribution. It doesn't require any server (though, I recommend you create an "RCS" folder in your source tree to store the RCS archives). After that, just start checking in and checking out revisions. It's simple. Plus, it integrates well into lots of editors on every operating system.

If you don’t need a lot of functionality and you’re already using Leopard you might use Time Machine for your needs. On the Dock you can select to create a snapshot manually.

I agree with those above who have said that Subversion doesn’t need to be complicated — you don’t have to use the trunk / tags / branch setup if you don’t want to.

Separate them out into a logical folder structure, and make sure you use logical log messages, and you’ll be fine. Learn what the tags are, as they may be useful in the future (there’s a great manual for SVN by Red Bean, free on that crazy world wide web), but really committing and reverting is all you really need to know if you’re the only user.

I love having SVN at work for my side projects that only I am working on. It gets easy, and I honestly prefer the command line to any of the GUI interfaces available for OS X.

Check out some of the distributed options (for a single developer, it usually also means no need to setup and run a server of any kind).

http://en.wikipedia.org/wiki/Distributed_revision_control
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software

My personal favorite is git. Its a content tracker, which is philosophically different. Its got a boat load of tools to do 'interesting' things with the repository. And its fast. Really fast. If you're a Windows user, you're shit out of luck (for now) though.

Also check out Hg.

You might want to check out unfuddle.com - they do all the server-side gruntwork, all you need to do is sign up for an account and get to work. Tortoise SVN is open-source and works great, very shallow learning curve IMO.

The past few years as a graphic designer in an all-Mac environment have taught me a few tricks for digital asset management. You'll find variations of this setup among various agencies and firms. I have a folder for Active Projects, and finished projects go in an "Archives" folder, where they wait to be burned to DVD. Each project folder has the project number at the beginning, with a descriptive name. Everybody has a different naming system. Some places use just numbers, and some combine letters with numbers. At my firm, we combine 2-3 letters that identify the client with a 4-digit job number. Each client starts at 1000. So if I were doing a project for you, Jamie, it would probably be JP-1000.

Each project folder has 6 folders in it: copy, final, images, proofs, support, and working. Copy contains text supplied by the client or written by our copywriter. Final contains the final collected files or press-ready PDFs, and I try to avoid placing this folder there until the end so as to avoid confusion. Images contains all flattened image files used in the layouts. Proofs contain all the proofs we send to our clients. Support is a little bit slippery: it's not quite copy, not necessarily image resources, but could be research material, inspiration, or some such other material that helps us arrive at the final product. The Working folder contains the layered Photoshop files and working layout documents. A Flash developer could keep .fla files here, and put .swf files in the Final folder.

Now that that's out of the way, here's how we manage versions/revisions. Normally, when things are comped (comprehensive layouts that are still open to revisions) we do 1 to 3 different layouts. These can be in one InDesign file in the working folder, with each layout on a different page. Or they can be named compA.psd, compB.psd, compC.psd, and so forth. We send clients proof PDFs. When we do a new revision to send to the clients, we append "_rx.pdf" to the file, where x equals the revision number.

So if we were doing a brochure for the Jamie Phelps company, it would have a project name like JP-1001-brochure. The layout would probably be named JP-1001-brochure.indd, and you'd get a proof named JP-1001-brochure.pdf. Let's say you want to modify some things, so we do that and send you a first revision. The first revision would be named JP-1001-brochure_r1.pdf. Ideally, it would get done in under 3 revisions.

Final files have "_f" appended to the name before the file extension. This is something of a holdover from the old Flightcheck software we used to use for preflighting Quark layouts, but it's a useful naming device to indicate that a project is finished and that this file is ready to go to press. Your final brochure would be in a folder named JP-1001-brochure_f or as a PDF named JP-1001-brochure_f.pdf inside the "final" folder, depending on how the printer prefers uploaded files, which we normally send via FTP.

I know it's a little different for web design and probably very different for programming, but I hope this helps. I think a consistent folder structure and naming system is key.

Not sure if this setup would help you, but this is how I run my version control.

First, 1 note about having the repositories hosted elsewhere... What happens if you are working without an internet connection? I've run into that problem a few times, and is one of the reasons I'm looking more at Git or Mercucial, with the ability to do offline commits.

That being said, I am a designer/developer who is constantly working both with binaries (flash, illustrator, psd and video files) as well as web related text files.

I orginally looked at using Adobe Version Cue, as a friend of mine is a big fan, but it was limited in the control you could have.

After setting up SVN, I have been very happy with using the following structure for almost all projects.

Each client gets a new repository, just to keep things simple, and to control access.
The file structure below that level is as follows.

Project#-Project Name
../branches
../tags
../trunk
../../creative
../../../comps
../../../assets
../../dev
../../../build
../../../interactive

That's the basic structure. I also have a folder for project management related items as well as a "legal" folder which has contract and billing related stuff.

svnX is a usable GUI, but I can't wait till versions comes out. http://versionsapp.com. It's been in development for a while, but really looks pretty sweet, and their other software is great.

I use dreamhost as a big backup disk, using macFusion and superDuper. I keep my dreamhost share mounted over ssh with macFusion, and superDuper backs up to it every night... I just recently had an issue where 3 of my repositories got corrupted, and being able to dl the backup from the day before was priceless.

1 benefit to hosting svn offsite is the ability to do svn checkout http://server/blah livewebsite. I get around this using dyndns.org to have a url that always tracks back to my computer, so I can do checkouts on any host that supports svn. I usually set up each site to have 2 domains, a staging and a live. Staging maps to the dev/build folder, and the live gets mapped to whatever the most recent release is. svn switch is great for flipping over to a new release on the live site.

I forgot to mention that I have the above folder structure set up in a repository, so that I can export it to a new project whenever needed. I do the same thing with my folder structure for websites as well, using a standardized setup of css and js files as well.

You don’t have to use a Subversion server to use Subversion, necessarily. I keep a repository for my personal projects and just have it as a network share on another system. I’d posted about how a while ago on my blog: http://qgyen.net/archive/using-subversion-without-a-subversion-server/ (Images are missing in the post, but has the steps). It is a simple, light weight way… no servers to install/setup, just install one of the desktop clients.

Do not even consider RCS for half a second!

It’s just not up to par with anything else. Merges are not as easy. Working with multiple directories on multiple systems requires either shared disk and soft links or other weird methods. It requires that files be locked, so only one person can edit them at a time. It’s only useful for 1 developer (it does support more, but not well) and only 1 host, and the web server makes 2 already.

CVS if you must, but RCS is not a contender. It needs to be left in the early 90s.

CVS comes with many Unix systems now, too. OS X comes with Subversion (new with Leopard AFAIK) and CVS.

As long as you’re starting a new project, you might as well use svn. It’s intended to supersede everything that came before it, and from what I hear (being still mostly stuck in cvs-land) it does a pretty good job.

Branching, merging, and the other esoteric concepts involved in source control are most relevant to a multi-developer team simultaneously working on multiple configurations of a single project. Ignore them to begin with; when you get to the point at which you need them, their meaning will suddenly become clear.

I wouldn’t consider anything newer than svn; there’s nothing as dependable as overwhelming mindshare as testimony to the stability of a product. There are other mature version control systems besides the continuing saga of rcs/cvs/svn, but they’re proprietary, not cheap, and thus not well suited to a single developer’s needs.

If you’re maintaining your own personal repository (server), keep it if possible on a separate machine, or at least on a separate disk; that way the server itself can serve as a backup of your working copy. Every time you make a change you don’t want to lose, check it in.

While this is fine for a personal repository, it’s not a good idea for a repository that you’re sharing with other people; your mistakes can propagate into their working copies and builds, and vice versa. Generally you want to make sure that your code at least passes your unit tests before you check it into a group repository.

Truth is there will be a learning curve with any versioning system. Subversion works with all types of files, it deals with directory structures better than anything else out there, and you can use TortoiseSVN to get around the command line thing if you really hate it. It works equally well from a Mac, a PC, or an Ubuntu box. It’s free. It’s open-source. It’s goodness.

I’d post it, but I keep getting moderated. So see here for my response. And if someone could figure out what I’m doing that triggers the moderation whenever I post a mildly-detailed explanation with a few links to relevant software, could it please be adjusted to something more sensible?

Definitely go with SVN, and definitely get the book recommended in the first post - I have it, and it taught me how to use SVN from scratch; It’s amazingly easy to understand.

I use SmartSVN, available at http://www.syntevo.com/smartsvn/index.html. It's available on the major platforms (Win, Mac, and Linux), is fairly straightforward to use, and most of all, free.

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

I’ve long been curious -does anybody use version control setups for writing that is not coding/markup etc.? Any novelists, journalists, poets, scholars using it?

Is is pure evil :) As some said look at Distributed VCS. I use Mercurial (Hg) and it has user interface very similar to SVN but works without server, configurations, etc.

I am a programmer and I use SVN where I have to. I even had SVN server for my own projects on local computer. But it just doesnt work. You can have one great repository for all you file or struggle with configuration and new server process for each of projects. With DVCS there is no such problem, everything needed by the VCS is stored in the directory. It just work great.

And for anyone still using SVN just look here: Tech Talk: Linus Torvalds on git. Maybe he is too cruel but if you think about it and give a try to DVCS you will now he is just right…

Another vote for Pragmatic Version Control: Using Subversion. Get this book. It makes it all so much easier.

My main piece of advice is use what’s good for you. Try them. Git will both import and export svn so you’re not locked in once you start. SVN is one of the most commonly used system, so it’s good to learn. GIT is probably a sign of things to come, so it’s probably also a good thing to learn.

As a web designer, the important thing you might want to learn is trigger scripts with either SVN or GIT. Trigger scripts are scripts run when specific events occur, like a commit. The obvious use of such scripts for the web is to have the trigger script update your website every time you commit. I do this for one of my web sites and it’s great not having to manually update the site after each commit.

to craig:

I use svn for things beyond programming. Here are a few examples:

1. Job hunting documents - resumes, cvs, draft cover letters. This is a great way to track how your info evolves through time, to keep versions organized, and to keep track of who was sent what. No more hunting through cd or dvd archives hunting for old versions; just pull out what you need from the repository.

2. complex documents - writing work that involves more than a single document, such as scientific work that requires associated data, complex plotting scripts, etc. to keep your text in sync with the associated information.

3. Reference databases - I use this mainly for syncing. Doesn’t work as well as I’d like.

You just need to be careful in terms of diffing files (finding the difference). Many file formats do not have a supported method to diff them. Text files are the easiest to diff. Some apps have specialized diffing tools, such as Word. If you can live with the diffing options for the files, and it’s work you plan to do progressively or collaboratively, version control might work for the project.

Long time svn user (and cvs in the dim dark days before that). Recently started using bzr but still feeling my way through a few issues with it.

If the command line is anathema to you, then I think svn is your only real option. As previously mentioned, smartsvn is a pretty good client that runs on macs (unlike tortoisesvn). As someone else already commented, you can use it in a purely local file shared mode if you don’t need remote access, although if you are already running an apache serer and know how to configure it a bit, it isn’t too hard to set up.

I started using svk, which is a pseudo-distributed source control system layered on top of svn, which isn’t bad to use if you have to use svn but like being able to do a bunch of commits locally and then push them all up when you’re ready (probably not a big issue for you).

I ended up using bzr because I had a requirement for doing a development project with a partner, and we had no access to an svn server for various reasons. With bzr, we are using a mutually accessible ftp server as our “central” repository that we push and pull our local changes to/from for each other.

The one thing I’ve found nice about bzr, git and mercurial is that unlike svn, which makes a “.svn” folder in each folder of your source tree, they only make one folder (“.bzr”, “.git”, etc) in the base folder of your tree. Its one of those things that I didn’t even know annoyed me until it wasn’t there anymore.

If you are having trouble getting your head around svn, I would use bzr or mercurial (hg) over git unless you wanted to make your head explode.

The one think I can identify about mercurial (and git for that matter) that I like over bzr is that it uses a hash (SHA1 I think, or MD5) to identify revisions and branches, which bzr does not. I can see some extreme usefulness in that. (Unfortunately neither mercurial or git could handle a repository over only FTP, which was the deal breaker in my recent project.)

And if you go with svn, contrary to what someone else said, I wouldn’t necessarily just use one big repository. I would at least use one per client. That way at least, you can easily archive off the repositories for old clients/projects without too much fuss.

And for the person asking about non-traditional uses of a source control program? I’m using bzr with a shared repository for my different eclipse installations. How’s that for untraditional? I basically have four flavours of eclipse that I use for various development: java, c++, php and ruby.

So I have the classic install, which I then branch to by base version. On the base version I install all the plugins that I want on every eclipse install no matter what (viPlugin being the primary one). Then I branch off that one for each of the eclipse flavours I am using.

That way, when it comes time to load updates, I can do them as the base version, and then pull those to all the child branches easily, then let them add their own specific updates.

It also means I can easily try a new plugin or an update to something, and if it doesn’t work or turns out to not be what I wanted, I can revert back to an earlier, stable version of my development tools.

[Brain dump complete]