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.
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!
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...
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 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
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.
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.
发布评论
评论（10）
基本上你可以讨论SVN可以做什么，它不仅仅是用于代码，而且可以用于一般的任何文档。
不提及代码的示例将很有用：
一位作者写了他的书并将其副本放在一个中心位置。 该文档名为 1。当他进行更改时，他将其副本命名为 2。下一个副本将命名为 3，依此类推。 只要他能够访问该中心位置，他就可以随时参考以前的副本。
现在，出版社已经为他的书指派了两名校对员。 通过SVN，校对人员能够更正词汇错误并进行更正，并将更正后的副本放在中心位置。 作者和校对者也能够获得最新的副本，并且他们可以阅读所做的更改，因为每当放置新副本时，相关人员都可以对已更改的内容发表评论。
如果校对人员发现逻辑和语法错误怎么办？ 他们不能简单地更改它并将新副本放在中心位置，因为他们不知道作者的意图，并且这可能是一种独特的写作风格（又名故意偏离规范的东西）。 他们可以使用错误跟踪软件，但那是另一篇文章的事了。
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.
当我读到这里有两件事。 1 教他们概念，2 教他们如何使用 SVN。
一般来说，保持简单，复杂性会随着时间和使用而自行解决。
简单地说，SVN 是您正在处理的内容的备份，但巧妙地只保存您所做的更改，而不是您保存到其中的每个版本，这样可以使其保持较小，并且可以轻松地让您比较随时间变化的更改。
这里的实践经验是无可替代的，向他们展示如何结账、更新和签入。 我建议你使用Tortoise SVN，因为学习曲线会大大缩短。
为了简单起见，我会建立他们自己的分支，他们可以提交，所以他们不需要理解这一点，你只需在后台管理合并。 但很快他们就会掌握窍门！
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!
向他们展示版本控制解决的问题应该是起点。
您可以让他们先执行
.bak文件来了解要点。但是，如果他们对维基百科足够熟悉，那么向他们展示历史以及维基百科如何保护自己（这会回答他们的一些好奇心）绝对会更好，这样他们就会发现它在实践中确实有用。 你可以安装一个维基让他们尝试。
只有之后，才将它们放入 svn 的“无聊”文本命令中......
Showing them the problem version control solves should be the starting point.
Either you could make them first do
.bakfiles 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...
最近，当我向整个 Web 开发团队（由程序员、界面构建者、图形设计师、内容编辑、网站管理员和非技术经理组成）介绍 SVN 时，我遇到了这个确切的问题。 我四处寻找非技术文档，但最终发现可用的文档很少，所以我决定构建自己的文档。 不幸的是，大多数信息都希望用户了解客户端/服务器架构以及“分支”是什么 - 在我的情况下我不能假设这一点。 您可以在 SlideShare 上查看我的迁移前 PowerPoint 之一（“这东西叫 SVN？FTW 还是 WTF？”）
真正的关键是解释 SVN - 从本质上讲 - 确实是只是复制和粘贴文件的更好方法。 摆脱default.bak、default2.asp、defaultBackup.asp、defaultMyCopy.asp 等...是每个人都能理解的事情。
随着我的用户越来越熟悉源代码控制的概念，我鼓励人们在我们的内部 WIKI 上提问，以便开发团队（和其他用户）可以帮助他们。
我们还构建了一个自定义 SVN 桌面工具，以一致的方式自动设置本地桌面，以便保证公司内的每个人都拥有与其他人相同的设置 (c:\projects\projectname)，并且它还更新了他们的本地桌面安装 IIS，以便他们可以随时在本地查看网站，而无需手动配置任何内容。
因此 - 提供大量指导 - 使用一些幽默 - 让事情变得简单 - 保持标准化 - 提供一种提问的方式 - <强>提供支持 - 确定您的用户以及他们“继续生活”的需求。 如果可能的话，坐在他们的办公桌前，根据需要多次引导他们完成整个过程，以帮助每个人克服障碍。
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?")
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.
我只想解释一个场景，其中跟踪以前的修订以及为客户建立一个分支很重要。
还有更通用的版本控制教程，这些教程并非特定于 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.
我发现 SVN 比 CVS 更容易解释，因为一切似乎都是文件夹（尽管它会使用浅拷贝）。 就这样跟他们解释一下就可以了。
并且不要详细解释所有内容，而只是在需要了解的基础上告诉他们。 如果你开始解释分支和合并，你可能会看到他们的头脑爆炸，或者他们可能会认为不值得为做出小的改变而付出努力
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
给“树干”、“树枝”等命名的树比喻怎么样？
How about the tree metaphor, which gave name to "trunk", "branch" etc?
告诉支持人员 SVN 是源代码服务器，他们所做的更改是客户端更改。 他们所做的是更改源代码的客户端副本。 它应该发布到 SVN 并存储在那里。 与任何其他客户端/服务器应用程序中的方式相同。
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.
告诉他们 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.
我发现这篇文章非常适合我们的新开发人员查看。 图表很好，信息也很简单。
分支与 Subversion 合并
真正的诀窍是他们了解分支的重要性，任何人都可以轻松掌握版本控制本身的概念。
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.