I work with a number of new tech support folks. Sometimes, they like to fix small issues which may not be a high priority for our developers. This requires teaching SVN basics to non-programmers, which I've found can get a little tricky.
What resources have you found useful? Are there diagrams you typically utilize to teach SVN?
I would just explain a scenario where tracking previous revisions is important as well as having a branch for a client.
There are more general version control tutorials out there that are not specific to svn or others that might be useful.
You don't want to overwhelm them - just give them the basic need for it.
I have found SVN a lot easier to explain than say CVS as everything appears to be folders (although it will use shallow copies). Just explain things in this manner to them.
And don't explain everything in detail, but rather just tell them on a need to know basis. If you start explaining branching and merging you may be able to see their head explode, or maybe they will think it is just not worth the effort for making small changes
Generally, I usually just give the Library metaphor; and have them think of their changes as such. I also post links to Wikis as needed.
Tell support personnel that SVN is a source code server and changes they make are client side change. What they do is change client copy of source code. It should be posted to SVN to be stored there. Same way as it is in any other client/serer applications.
Basically you can discuss what SVN can do, that it's not just for code, and can be used for any documents in general.
Examples without mentioning code will be useful:
An author writes his book and put a copy of it in a central location. That document is named 1. When he makes a change, he puts a copy of it named 2. The next copy will be named 3 and so on. He can always refer to previous copies if he wants at any point of time as long as he has access to that central location.
Now, the publishing company have assigned two proofreaders to his book. With SVN, the proofreaders are able to correct vocabulary mistakes and correct them and put the corrected copy at the central location. The writer and the proofreaders are able to get the latest copy as well, and they can read the changes made because whenever a new copy is placed, the person involved can write comments about what have been changed.
What if the proofreaders find logical and grammatical mistakes? They cannot simply change it and put a new copy to the central location as they do not know the writer's intention and it could possibly be a unique writing style (aka something intentionally deviating from the norm). They can use a bug tracker software but that's for another post.
Showing them the problem version control solves should be the starting point.
Either you could make them first do .bak files first to see the point.
But if they are sufficiently familiar with Wikipedia, it would be definitively better to show them history and how wikipedia protects itself (it would answer some of their curiosity), so that they see it's really usefull in practice. You could install a wiki to make them try.
Only afterwards, put them in from of the 'boring' textual commands of svn...
It can be a good idea to tell them that SVN can be used for other things besides programming. Configuration files, documents, anything basically that you need versioned or even just backed up.
Teach them about the repository, in which all the files and the information about the different versions of the files exist, and about the working copy which are the files that you actually work with.
Start with the simple stuff like checking files out and committing. Committing files is like saying: "I have a new file or a new version of a file". Show them how to keep the files updated with the newest versions.
Maybe then you can start telling them about the trunk, branches and tags, merging and all that jazz. A great resource are the non-programmers who've actually learned something. They can probably use phrases and analogies that are more suitable for other non-programmers.
As I read it there are 2 things here. 1 teaching them the concept, and 2 teaching them how to use SVN.
Generally keep it simple and the complexity will take care of its self in time and use.
Simply, SVN is a backup of what you are working on, but cunningly only saves the changes you make not every version you save to it, this keeps it small and easily allow you to compare changes over time.
There is no substitute for practical experience here, show them how to checkout, update and checkin. I would suggest you use Tortoise SVN as the learning curve is greatly reduced.
To keep things simple I would set up their own branch they can commit to, so they don't need to understand that yet, and you just manage the merges in the background. But soon they will get the hang of it!
I ran into this exact issue recently as I introduced SVN to the entire web dev team (consisting of programmers, interface builders, graphic designers, content editors, site moderators, and non-technical managers). I looked around for non-technical documents but ended up with very little that was usable so I decided to build my own. Unfortunately the majority of info out there expects users to know about client/server architecture and what a 'branch' is - I could not assume that in my case. You can view one of my pre-migration PowerPoints over at SlideShare ("What Is This Thing Called SVN? FTW or WTF?")
http://www.slideshare.net/secret/wBsLzZb3O7cXCU
The real key was to explain that SVN - at its heart - is really just a better way to approach copying and pasting files. Getting rid of default.bak, default2.asp, defaultBackup.asp, defaultMyCopy.asp, etc... was something that everybody could understand.
As my users became more familiar with the idea of source control I encouraged people to ask questions on our internal WIKI so that the dev team (and other users) could help them out.
We also built a custom SVN desktop tool to auto-set up their local desktop in a consistent way so that everybody across the company was guaranteed to have the same setup as everyody else (c:\projects\projectname) and it also updated their local IIS installation so that they could view websites locally at any time without needing to configure anything by hand.
So - provide lots of hand-holding - use some humour - make things simple - keep it standardized - provide a way to ask questions - provide support - identify with your users and their need to "get on with their day". And if possible, sit at their desk and walk them through the process as many times as is necessary to get each person over the hurdle.
I find this article to be really good for our new developers to look at. The diagrams are good and the information is pretty simple.
Branch Merging With Subversion
Really the trick is getting them to understand the importance of branching, anyone can easily grasp the concepts of revision control itself.