SVN最佳实践-在团队中工作

Question

我要从SVN开始。我知道基本的命令和基本原则。我想知道是否有人有在团队环境中使用Subversion的任何技巧或最佳实践。

在提交代码时，我可以看到添加相当冗长的消息的好处，但是还有其他的事情我应该记住吗？

感谢所有伟大的答案--他们帮了很多忙。

Answer 1

鼓励频繁提交。新加入版本控制的队友可能觉得他们需要将代码从存储库中删除，直到“它正常工作”为止。教每个人尽早作出承诺，并经常尽快发现问题。建议您的队友为可能破坏主干的特性创建分支，而不是将代码保持到“工作”为止。

建立分支和标记实践。除了分支的特性外，还鼓励您的队友使用分支进行大bug修复。标记主要错误修复在开始和结束的工作。维护生产/qa发行版的标记(可能还包括分支)。

为主干建立了一个策略并坚持它。的一个例子可能是：“主干必须始终构建没有错误。”或者“主干必须始终通过所有单元测试”。任何尚不能达到干线标准的工作都必须在分支机构中完成。

Answer 2

我一直坚持的关键概念之一是一起提交相关的代码更改，。由此得出的结论是，不会在同一个提交中提交无关的代码更改。这意味着不要在一次提交中修复2个bug (除非是相同的修复)，也不要在每个提交中提交半个bug修复。另外，如果我需要向系统中的一个不相关的部分添加一些新的增强或者什么东西，然后我需要做一些其他的工作，我会分别(首先)提交增强。其想法是，任何人可能希望自己进行的任何更改(或自行回滚)都应该是单独的提交。当需要做合并或回滚破碎的功能时，它将为您节省大量的头痛。

Answer 3

人们已经提到了很多，下面还有一些：

1. 如果在源代码管理中有不想要的文件(例如，配置、编译的文件等)，那么将它们添加到忽略列表中。通过这种方式，您会注意到忘记添加的任何文件，方法是总是期待一个空的文件列表，显示SVN未知的文件。
2. 添加一个post提交事件，该事件将向您的开发人员邮件列表(或特定于此目标的邮件列表)发送一封与所提交的更改相关的电子邮件，并在理想情况下发送用于此更改的修补程序。
3. 与您的bug跟踪器集成，以便提交的引用显示在带有差异链接的bug/特性请求上。像MantisBT这样的Bug跟踪器支持这一点。
4. 考虑与连续集成(例如CruiseControl.NET)、用于构建的NAnt和用于单元测试的NUnit/VS集成。这样，一旦用户签入代码或按计划间隔编译代码，单元测试就会运行，开发人员就会得到流程的反馈。如果存储库被破坏(即不构建)，这也会提醒团队的其他成员。