我的许多同事以1-5人为一组使用SVN，部分工作于特定项目。他们中有一半是没有经验的学生。实际上，我们当中没有一个是拥有一年经验的真正的软件开发人员。他们中的大多数人使用Eclipse和subclipse来读取和写入对SVN存储库的贡献。

其中一些在以下方面存在问题：

• 签出(与更新和合并混淆)
• 提交(与更新混淆)
• 更新(与提交和签出混淆)
• 合并(最困难。什么是合并？我是否必须将代码"合并到SVN"中？)

他们担心如果按下错误的按钮，SVN可能会杀死他们的工作(他们不称其为工作分支)。

在向Java项目添加任意库依赖项之后，他们将eclipse .project文件提交到存储库中。其他同事从这些计算机上得到编译错误，发现很难解决这些错误。

他们通常会说：我想在没有SVN的情况下工作，我不喜欢它。太复杂了。

是否有像" SVN for kids"这样的电子学习项目？如何使它们像版本控制一样？

解决方案

试试这个。我在" SVN for Dummies"搜索中找到了它，并被描述为" SVN for Dummies，我们奶奶可以理解的指南"：D

给他们一个关于svn的简短演讲。告诉他们好处是什么以及如何使用它。

尽管我在使用乌龟SVN的文件系统级别上使用了SVN，但我在大学毕业后的第一份工作中就设法做到了这一点。我不是那么聪明，所以如果我能捡起它，任何人都可以。

最好的方法是对所需过程进行简单的"备忘单"，并逐步进行操作。 SVN确实存在一些不明显的陷阱。我参与了使用它的新人们，有时他们确实从当前版本中删除了整个代码块，等等。当然，我们总是可以回过头来从以前的版本中获取代码，但是SVN令人恐惧和危险新人。请记住这一点，并为所需的操作编写非常简单但明确的说明！

如果主要是学生，那么一个卖点就是在"真实世界"中，很多人都非常重视版本控制。

如果他们害怕删除某些内容，请演示删除一些关键文件，并演示恢复已删除文件的能力。

或者他们可能希望一起使用另一种版本控制，例如git或者mercurial。

这是描述基本用法的体面的SVN"备忘单"：http://abbeyworkshop.com/howto/misc/svn01/

与他们一起运行一些方案，以了解为什么版本控制良好。更好的是，将它们带入一些玩具项目中，这些项目的时间压力使它们经常投入工作。在某些情况下，只允许他们通过svn共享代码，而在另一些情况下，仅允许它们通过共享目录共享代码。

之后，他们会知道它的含义。

K让你的朋友读这篇。接下来在一些宠物项目上首先学习cli可以大大澄清这一点。我第一次参加亚食会议使我讨厌日食。部分原因是我以前从未使用过subversion。

• 签出=获取存储库中代码的本地副本。
• 更新=确保本地副本与主副本保持最新。又名服务器。
• commit =将更改添加到主副本
• 合并=我们加上我们自签出后提交的其他人。合并允许我们通过一点点监督的编辑来保留两组更改。

合并是一个很好的功能，但是乍一看有点复杂。

我建议他们至少阅读http://svnbook.red-bean.com/en/1.5/index.html的基本部分，它写得很好，并带有一些幽默。它涉及使用命令行工具，但是无论我们使用哪种界面(例如TortoiseSVN或者Subclipse)，这些概念都是相同的

SVN会跟踪自项目启动以来的所有更改，因此几乎没有办法仅通过单击"错误"按钮就放弃工作。我真的认为，即使没有团队(我自己编写代码，也使用它)，所有重要的工作都应该在版本控制下。

在读完这本小书之前，我从来没有真正理解过重点，请尝试使他们至少阅读前20页。在subversion和任何编辑器的"撤消"按钮之间有一个很好的类比，可以说服他们使用它(它与我合作:))

"如何使它们像版本控制一样？"

删除他们的工作副本，他们将迅速掌握版本控制软件的实用性！

认真地说，使用VCS与成为成熟的开发人员是密不可分的。如果我们不知道为什么要使用Subversion，那么我就不会相信他们是开发人员。他们可能具有编程技能，但是编程只是成为开发人员的一部分。

我相信，在我们丢失代码之前，我们将永远不会真正欣赏VCS。

• 无限撤消-无需担心丢失的更改
• 备份，不再是责任
• "时间机器"功能-上周五晚上的代码是什么样的？
• 合作
• 中央的"官方"源代码版本易于构建发行版
• 比较：某人敢于触摸代码，他究竟做了什么更改？
• 标记：标记准备演示的稳定版本，之后我们可以继续在代码库中进行开发

仅当两个开发人员在同一源文件中修改同一行时才需要"合并"。在小型团队中，这种情况很少发生，需要花费几分钟的时间来解决。所有其他更改都由版本控制系统自动合并。

将它们发送到：

• http://svnbook.red-bean.com/
• http://www.ericsink.com/scm/source_control.html

给他们留下深刻的印象，即使用半透明的源代码控制系统(即不是VSS)的任何人都将它们视为完全和愚蠢的人。

首先，我们需要采取"独立于软件"的方法来解决此问题。不要强迫他们阅读Red Bean一书，也不要尝试告诉他们所有漂亮的SVN命令。相反，我们应该首先尝试通过版本控制来教授正确的工作流程。简而言之，这意味着：

• 更新你的看法
• 做一些改变
• 测试你的代码
• 再次更新
• 如有必要，解决合并冲突
• 犯罪

请注意，我不包括初始签出流程，因为我们应该在那里帮助他们签出他们的初始视图。上面的步骤只是启用SCM的开发人员每天应该做的(顺便说一句，我们还应该强调一点，否则，担心合并冲突的人只会随着时间的推移而变得更糟)。

成功采用SCM的关键是双重的。首先，我们需要让人们习惯使用该软件来完成正常，无痛苦的事情(即更新/提交)。如果我们不这样做，那么开发人员将倾向于避免使用SCM，直到我们困扰他们，并询问为什么他们两周内未提交任何代码。其次，我们需要教人们如何克服可能使他们失去工作的常见痛苦情景。

SCM系统确实有可能破坏工作，并且通常会在任何东西因合并冲突而提交到存储库之前发生。我们应该模拟合并冲突，逐步解决它们，然后让它们自己执行相同的操作。我们应该解释：

• 冲突后.r1，.r2，.mine和原始文件的含义是什么
• 显示如何以图形方式解决冲突
• 现在重新编译并再次测试软件，以确保
• 再次备份.mine文件，只是为了确保
• 然后提交

SCM中还有许多更复杂的事情，只有在充分理解基础知识之后，才应对此进行解释。甚至在他们有几周的日常工作经验之前，都不要再提及合并或者标记之类的事情。否则，复杂性和额外的风险将使这种新工具对他们而言显得更加"无用"。

同样，这里的关键是要以软件中立的方式强调日常SCM工作流程，并在出现时慢慢解释特定SCM系统的怪癖。合并是首先需要解释的唯一复杂的事情，因为它很可能是每天遇到的唯一痛苦的事情。其他一切都应在出现时加以解释。

我们首先需要真正在版本控制的概念上出售它们，以便他们了解svn的工作原理。

可以尝试的一些方法是

• 创建用于训练和实验的沙箱存储库
• 尝试组织一些培训课程/讲习班。如果我们不确定自己该如何运行，请尝试与本地Linux用户组聊天，以了解他们是否认识可以提供帮助的人。
• 记录开发过程，包括常见的Subversion使用方案。

还值得向有经验的学生指出，具有源代码控制的经验将是他们简历的加分项。

关于提交.project文件的特定问题，我们可以在属性上设置svn：ignore属性，也可以在每个用户subversion配置文件中设置global-ignores值。

你真的不能让任何人喜欢它。但是，如果我们自己开始使用它并树立好榜样，那么好处将显而易见。我们需要不断更新服务器，并确保已备份服务器。这样，当系统中存在疯狂的错误时，我们将拥有日志以显示导致该错误的更改。你知道你需要做什么。不要让别人的无知阻止你。

我们可能想要为最危险的命令(我主要是考虑还原)创建别名，这些别名在调用svn命令之前需要明确确认。

另外，如果他们使用的是Eclipse，则可以设置其编辑器，以保留当前代码的N个工作副本。该功能使我避免了几次愚蠢的版本控制错误。

以我的经验，这么多人"害怕"或者不喜欢版本控制的主要原因之一是因为他们不了解底层概念以及系统的工作方式。不幸的是，许多经验丰富的开发人员也是如此。我知道使用CVS和Subversion已有多年的人，但是他们从未创建分支或者标签，因为他们不了解它们的工作方式，因此将它们视为"复杂的"或者"不必要的"。

我认为至关重要的是，同事必须对版本控制的目的，使用它的原因以及其中涉及的工作流程有基本的了解。就个人而言，我认为Subversion本书的前两章提供了对所涉及概念和版本控制系统背后的理论的最佳解释，因此，我建议同事阅读这些内容。

我不建议使用IDE集成来学习使用版本控制。集成和插件通常会向用户隐藏系统的"细节"，这可能非常令人困惑，尤其是在我们不知道"幕后"情况如何的情况下。

我更喜欢TortoiseSVN之类的工具，我们可以在其中直接或者手动执行大多数操作，而无需在幕后进行任何"魔术"操作。例如，一个非常普遍的误解是不了解工作副本与服务器上存储库之间的区别。我经常看到切换到直接在文件系统上操作的工具将有助于解决这种情况，因为用户不得不主动思考自己的工作及其原因。

与生活中的几乎所有其他一切一样，使用版本控制也可以通过个人尝试和失败，然后重试来达到最佳效果。这就是为什么我建议为每个人创建沙箱主文件夹的原因。让他们可以尝试系统中的各种功能，而不必担心破坏项目中的任何内容或者丢失数据。

他们总是可以尝试"穷人的CVS"：让他们在签入/签出任何内容之前先对其代码进行ZIP处理，然后将编号存储在硬盘中。

最后，他们将拥有一堆文件，例如：

• MyProject01.zip
• MyProject02.zip
• (等等)

这应该使他们想到，如果他们做一些愚蠢的事情，他们的"工作"就不会被"破坏"，并且会很累赘，迫使他们学习如何正确地使用SVN(来吧，这并不困难！ )。

我个人发现，这个可怜的人的方法远胜于Visual SourceSafe：在前雇主的情况下，我被迫使用这种怪兽...在存储库第二次完全崩溃之后，他们为此表示感谢：D

如果我们在Windows计算机上进行开发，请尝试将TortoiseSVN用作Subversion客户端。界面真的很棒。我他们放松对版本控制的恐惧。

版本控制最大的问题是冲突的解决。如果我们确实想安全玩游戏，请尝试以下工作流程：

• 每个开发人员在开始编写代码之前都会从主干创建一个分支。
• 开发人员在自己的分支中实现功能并提交(无需更新，因为他是其分支中的唯一开发人员)；
• 一些经验丰富的开发人员检查代码，测试并将分支修订合并到主干中。
• 冲洗并重复

Subversion 1.5的新功能对于这种工作流程确实非常有用。

这完全取决于对使用新事物的信心，并了解他们使用的是什么。使用它后，很高兴它能起作用，"分歧"消失了。

首先尝试培训概述，这是一个提供一些PowerPoint幻灯片以提供帮助的项目。

给他们提供svn书，并链接到TortoiseSVN，以便在获得概述后继续阅读。

然后尝试一个带有沙箱仓库的动手工作坊。

然后可以在一周左右的时间内为他们提供帮助。

这种方法适用于所有事物，而不仅限于SVN。