Answers:
鼓励频繁提交。 刚接触版本控制的队友可能会觉得他们需要将代码保留在存储库之外，直到“其工作正常”为止。教会每个人尽早做出承诺，并经常尽快发现问题。建议您的队友为可能会破坏主干的功能创建分支，而不是仅仅保留代码直到起作用。导致...
建立分支和标记实践。 除了功能分支外，鼓励您的队友使用分支进行大型错误修复。标签主要错误修复在工作的开始和结束时进行。维护用于生产/质量检查发布的标签（可能还有分支）。
建立中继策略并坚持下去。 一个例子可能是，“行李箱必须始终没有错误地建造”。或“行李箱必须始终通过所有单元测试”。任何尚不能满足中继标准的工作都必须在分支机构中完成。
不要通过代码更改提交格式更改
如果要重组巨型文件的空白（Control+ K+ D），可以。提交格式更改与实际逻辑更改分开。如果要在文件中移动功能，也是如此。与实际编辑分开提交移动。
我一直坚持的关键概念之一是将相关的代码更改一起提交。结果是不要在同一提交中提交无关的代码更改。这意味着不要在一个提交中修复2个错误（除非是相同的修复），也不要在2个提交中的每个提交中都修复一半的错误。另外，如果我需要向系统的不相关部分添加一些新的增强功能或其他一些其他工作所需的功能，则可以单独（并且首先）提交增强功能。这样的想法是，任何人可能想独自拥有（或自行回滚）的任何更改都应单独提交。进行合并或回滚损坏的功能时，它将为您节省很多头痛。
已经提到了很多，这里还有更多：
如果您有不需要的文件（例如配置，编译文件等），请将其添加到忽略列表中。通过这种方式，您总是会期望看到一个空白列表，这些副本使SVN未知，从而使您忘记添加任何文件。
添加一个后提交事件，该事件将向您的开发人员邮件列表（或针对该目标的邮件）发送一封电子邮件，其中涉及已提交的更改以及理想的补丁程序。
与您的错误跟踪器集成，以便对提交的引用显示在具有差异链接的错误/功能请求中。像MantisBT这样的Bug跟踪器支持此功能。
考虑与持续集成（例如CruiseControl.NET），用于构建的NAnt和用于单元测试的NUnit / VS 集成。这样，一旦用户签入代码或在计划的时间间隔内对代码进行编译，运行单元测试，并且开发人员就可以获取该过程的反馈。如果存储库已损坏（即未构建），这还将提醒团队的其他成员。
好吧，基础知识：
人们给出的答案很棒。svn用户文档中总结了许多此类内容，以获取SVN的最佳做法。
重复：
我想总结一下我坚持的最佳实践：
应该有存储库结构。我个人使用以下存储库结构：
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
PA（pre-alpha），A（alpha），B（beta），AR（alpha-release），BR（beta-release），RC（release候选），ST（stable）。我发现非常有用的一件事是svn：external属性，这意味着您可以将其他存储库中的目录引用到您自己的目录中。它提供了组织代码和数据的非常好的方法。一些例子是：
与您的错误跟踪软件一起使用集成。如果您使用Bugzilla，则可以对其进行设置，如果您的注释以“ Bug XXXX”开头，则您的SVN注释会自动添加为给定错误的注释，包括指向该修订版的SVN Web界面的链接。
如果您使用的是与SVN良好集成的良好工具，那么它将变得更加容易。这些功能使您可以轻松查看已更改的内容，然后提交所有或部分更改，并经常将工作副本更新为SVN中的最新版本。
我建议使用Tortoise SVN（如果使用Windows）和Visual SVN（如果使用VS）。
另请查看是否可以进行设置，以便在提交更改时随时收到电子邮件或类似的通知（通常还包括提交消息和更改文件列表）。像CVSDude这样的服务提供了这一点。我发现了解已进行的更新，然后在更新工作副本之前对更新中包含的内容有所了解会很有帮助。
使用SVN的最佳做法：
第一次上班并打开Eclipse项目时，第一步必须是更新项目。
更新后，开始工作。完成编码后，请正确检查编码，应用程序是否正常运行而没有任何例外。一旦确定代码可以正常工作，就可以提交代码了。
注意：提交代码时，请勿直接提交。与服务器进行同步，并检查所有需要提交的内容。注意：不要一次提交整个文件夹。因为您可能已根据需要对文件进行了一些更改，或者可能已删除了本地系统中的某些文件。但是服务器上的设置不同。因此，请单独检查文件并提交代码。
不要直接提交/更新冲突文件。
何时进行覆盖和更新？
当您非常确定不需要任何本地更改并且想要完全更新服务器副本时。请注意，一旦执行覆盖和更新，就不会获得任何本地更改。
注意：不要在没有更新的情况下保留项目超过一天。也不要在没有提交很多天的情况下保留代码。
交流谁都在同一组件中工作，并讨论他们每天所做的更改。
除非有某些原因，否则不要提交属性和配置文件。因为服务器和云中的设置将不同。
不要将目标文件夹提交到SVN中，只需将源代码和资源文件夹维护在SVN存储库中。
当您丢失代码时，不要惊慌！您可以从SVN历史记录中获取较早的副本。
不要将项目签出到磁盘的多个位置。在一个位置签出并使用它。
SVN本身就是一个好的开始，其他一些发布者也提供了一些有关最佳实践的好建议。
我唯一要补充的是，您应该将SVN与CruiseControl或TeamCity挂钩，以驱动持续集成过程。这将发送构建电子邮件，并在有人破坏构建时通知所有人。
这将在很早的时候告诉您谁在遵循您的流程，谁没有遵循。可能会导致一些磨擦，但从长远来看，您的团队会变得更好。