如何让我的同事不要鄙视SVN？

Question

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

他们中的一些人有以下不同的问题：

• 签出（与更新和合并混淆）
• 提交（与更新混淆）
• 更新（与提交和签出混淆）
• 合并（是最难的。什么是合并？我必须将我的代码合并到SVN中吗？）

如果他们按错了按钮，他们担心SVN可能会杀死他们的工作（他们不称之为工作分支）。

在将一些任意库依赖项添加到其java项目之后，他们将eclipse .project文件提交到存储库。 其他同事从这些comitts得到编译错误，并发现很难解决这些问题。

一般来说，他们说： 我想在没有SVN的情况下工作，我不喜欢它。 这太复杂了。

有没有像“SVN for kids”这样的电子学习项目？ 我怎样才能让它们像版本控制一样？

Answer 1

根据我的经验，为什么这么多人“害怕”或不喜欢版本控制的一个主要原因是因为他们不了解基本概念以及系统如何工作 。 不幸的是，对于许多有经验的开发人员来说，这也是如此。 我知道多年来一直使用CVS和Subversion的人，但他们从不创建分支或标签，因为他们不了解它们是如何工作的，因此将它们视为“复杂”或“不必要”。

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

我不建议使用IDE集成来学习使用版本控制 。 集成和插件通常会隐藏用户的系统“细节”，这可能非常令人困惑，特别是如果你不知道“引擎盖”之类的东西。

我更喜欢像TortoiseSVN这样的工具，你可以直接执行大多数操作，也可以手工操作，在幕后没有任何“魔法”。 例如，一个非常常见的误解是不了解工作副本与服务器上的存储库之间的差异。 我经常看到，切换到直接在文件系统上运行的工具将有助于解决这种情况，因为用户被迫主动思考他在做什么，以及为什么。

与生活中的其他一切一样，使用版本控制也是最好的个人经验 - 尝试和失败，并再次尝试。 这就是我建议为每个人创建沙箱主文件夹的原因 。 允许他们在系统中试验各种功能，而不必担心破坏项目中的任何内容或丢失数据。

Answer 2

首先，您需要采用“独立于软件”的方法来研究这个问题。 不要强迫他们阅读Red Bean书籍，或者尝试告诉他们所有漂亮的SVN命令。 相反，您应该首先尝试使用版本控制来教授正确的工作流程。 简而言之，这意味着：

1. 更新您的视图
2. 做一些改变
3. 测试你的代码
4. 再次更新
5. 如有必要，解决合并冲突
6. 承诺

请注意，我将排除初始签出流程，因为您应该在那里帮助他们查看他们的初始视图。 上述步骤只是SCM支持的开发人员每天应该做的事情（顺便说一句，你也应该真正强调这一点，否则那些担心合并冲突的人只会随着时间的推移而变得更糟）。

SCM成功采用的关键是双重的; 首先，您需要让人们习惯使用软件来处理正常的，非痛苦的事情（即更新/提交）。 如果你不这样做，那么开发人员将倾向于避免使用SCM，直到你为此烦恼并询问为什么他们在两周内没有提交任何代码。 其次，你需要教会人们如何克服可能导致他们失去工作的常见痛苦场景。

SCM系统确实可能会破坏工作，并且通常在任何事件通过合并冲突提交到存储库之前发生。 你应该模拟合并冲突，让他们解决它们，然后让它们自己做同样的事情。 你应该解释一下：

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

境内有许多SCM更复杂的事情，而这只能更晚后基本是很好理解的解释。 甚至不用提及合并或标记或类似的东西，直到他们有几周的日常经验。 否则，复杂性和额外的风险将使这个新工具对他们来说更加“无用”。

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

Answer 3

对于所需程序的简单“备忘单”，一步一步给出，是最好的方法。 SVN确实有一些不明显的陷阱。 我已经参与了使用它的新人，有时他们会从当前的版本中删除整个代码块等等。当然，你总是可以回过头来获取以前的版本，但是SVN 是可怕的和危险的新人。 牢记这一点，并为所需的操作编写非常简单但明确的指令！

Answer 4

“我怎样才能让它们像版本控制一样？”

删除他们的工作副本，他们将很快掌握有用的版本控制软件！

说真的，使用VCS与成熟的开发人员并驾齐驱。 如果你不知道为什么你想要Subversion，我不会相信他们是开发者。 他们可能有技能编程，但编程只是开发人员工作的一部分。

我确实相信，在你丢失代码之前，你真的永远不会欣赏VCS。

Answer 5

• 无限撤消 - 无需担心丢失的更改
• 备份，不再是你的责任了
• '时间机器'功能 - 上周五晚上的代码是什么样的？
• 合作
• 中央，“官方”版本的源代码使得易于构建版本
• 比较：有人敢碰你的代码，他究竟改变了什么？
• 标记：标记稳定版本，可以进行演示，您可以继续在代码库中进行开发

只有当两个开发人员修改相同源文件中的同一行时才需要'合并'。 它在小团队中并不经常发生，需要几分钟才能解决。 版本控制系统自动合并所有其他更改。

Answer 6

如果他们大多是学生，那么在“现实世界”中有一个卖点就是很多人非常重视版本控制。

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

或者他们可能喜欢不同类型的版本控制，例如git或mercurial。

Answer 7

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

我设法在大学的第一份工作中拿起SVN并没有遇到任何麻烦，尽管我在使用tortoise SVN的文件系统级别使用它。 我不是那么聪明，所以如果我可以拿起它，任何人都可以。

Answer 8

与它们一起运行一些场景，了解为什么版本控制是好的。 更好的是，让他们通过一些玩具项目，时间压力使他们经常提交。 在某些情况下，只允许它们通过svn共享代码，而在其他情况下只能通过共享目录共享代码。

之后他们会知道它是什么。

Answer 9

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

Answer 10

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

1. 在开始编码之前，每个开发人员都从主干创建一个分支;
2. 开发人员在他自己的分支中实现一个功能并提交（不需要更新，因为他是他的分支中的唯一开发人员）;
3. 一些更有经验的开发人员审查代码，测试并将分支修订合并到主干;
4. 冲洗并重复

Subversion 1.5新功能非常适合这种工作流程。

Answer 11

试试这个 。 我发现它是'SVN for dummies'搜索，它被描述为'傻瓜SVN，奶奶可以理解的指南'：D

Answer 12

这是一个体面的SVN“cheatsheet”，描述了基本用法： http ： //abbeyworkshop.com/howto/misc/svn01/

Answer 13

K让你的朋友读这个。 接下来，在几个宠物项目中首先学习cli可以大大澄清这一点。 我第一次看到subclipse让我讨厌eclipse。 部分是因为我之前从未使用过颠覆。

• check out =获取存储库中代码的本地副本。
• Update =确保您的本地副本与主副本保持同步。 又名服务器。
• commit =将更改添加到主副本
• merge =你加上其他人已经提交了你已经提交。 合并允许您通过一点监督编辑保留两组更改。

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

Answer 14

我建议他们至少阅读基本部分 http://svnbook.red-bean.com/en/1.5/index.html ，它写得很精彩。它涵盖了使用命令行工具，但无论你是什么界面，概念都是一样的使用（即TortoiseSVN或Subclipse）

Answer 15

SVN跟踪项目启动后的所有变化，因此几乎没有办法通过点击“错误”按钮丢弃你的工作。 我真的认为所有重要的工作都应该在版本控制之下 ，即使没有团队（我只使用代码并使用它）。

在我读完这本小书之前 ，我从未真正看到过这一点 ，试着让它们至少阅读前20页。 在subversion和任何编辑器的“撤消”按钮之间有一个很好的类比，这可能说服他们使用它（它与我合作:)）

Answer 16

发送给：

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

给他们留下深刻印象的是，任何使用半个合适的源控制系统（即不是VSS）的人都会将他们诋毁为完全和彻底的傻瓜。

Answer 17

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

要尝试的一些事情是

• 创建沙箱存储库以进行培训和实验
• 尝试组织一些培训课程/研讨会。 如果您对自己的运行没有信心，请尝试与当地的Linux用户组聊天，看看他们是否认识可以提供帮助的人。
• 记录您的开发过程，包括常见的subversion使用场景。

值得向学生们指出，源代码控制经验对他们的简历来说也是一个优势。

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

Answer 18

您可能希望为调用svn命令之前需要显式确认的最危险命令（我主要考虑恢复）创建别名。

此外，如果他们使用Eclipse，他们可以设置他们的编辑器，以便它保留当前代码的N个工作副本。 我已经从这个功能的几个愚蠢的版本控制错误中拯救了自己。

Answer 19

他们总是可以尝试“穷人的CVS”：让他们在签入/退出任何东西之前做一段他们的代码，并将它们存储在硬盘中的某个地方。

最后，他们会有一堆文件，如：

• MyProject01.zip
• MyProject02.zip
• （等等）

这将使他们明白他们的“工作”不会被“摧毁”以防他们做一些愚蠢的事情，并且会非常麻烦，迫使他们学习如何正确使用SVN（来吧，这并不难！ ）。

我个人发现这个穷人的方法远远优于Visual SourceSafe：在一个前雇主我被迫使用那个怪物......在第二次存储库完全崩溃后，他们感谢我：D

Answer 20

如果您正在使用Windows机器进行开发，请尝试使用TortoiseSVN作为您的subversion客户端。 界面真的很棒。 我会帮助他们摆脱版本控制恐惧。

Answer 21

这完全取决于使用新东西的信心，并了解它们正在使用的东西。 一旦你使用它，它很高兴它有效，'分歧'消失了。

首先尝试培训概述 - 这是一个提供一些powerpoint幻灯片的项目 。

给他们一本svn书并链接到TortoiseSVN，一旦他们有了概述，就可以阅读它。

然后尝试一个带沙盒回购的实践工作坊。

然后可以在他们真正使用它的同时提供一周左右的帮助。

这种方法适用于所有方面，而不仅仅是SVN。