我们应该将规范文档放在svn这样的源代码控制系统中吗？

今天，我和我的一位同事辩论了“我们应该将规范文档放到诸如SVN之类的源代码控制系统中吗？”。我认为应该是。与开发项目有关的一切都应使用源代码控制系统进行仔细控制。在软件开发过程中这是一个错误的概念吗？

那么，如果大多数源代码控制系统仅将它们存储为Blob，该怎么办？大多数人都不会细谈文档之间的差异，但是如果您这样做，您总是可以得到两个版本，并使用创作系统的功能来差异它们。

由于硬盘空间为每月每GB几美分，因此没有充分的理由不将文档放入源控制系统中，这很有用。我个人的喜好是使用内联标记（例如Wiki Markup或DocBook）编写文档。这允许使用功能强大的工具进行文档比较和修订。

对规范文档进行版本控制绝对是一个值得追求的目标。

但是，规范文档仅是纯文本文件，还是纯文本文件？如果是这样，这可能是一个很好的解决方案。

如果不是这样，则源代码管理可能不是适合他们的地方- 源代码管理对二进制文件不利。

通常，纯文本文件既不适合格式设置也不适合快速查看，因此带版本控制的Wiki可能是一个更好的主意。

所有文档都应采用某种存档形式（最好带有修订控制）。

源代码管理系统是一种解决方案。但是通常这些系统是为纯文本文档设计的。因此，Word或RTF文档等内容不太适合（尤其是当您尝试比较不同版本时）。

但是，还有其他专为文档设计的解决方案。想到了SharePoint，但我敢肯定还有其他人。

绝对是 文档存储为二进制文件（例如Word文档）的问题很烦人。一个不错的解决方法是，如果您使用其中一种Tortoise工具（我已经尝试过SVN和Mercurial），则可以选择“ Visual Diff”，以使您可以选择docdiff。使用docdiff，您可以看到颜色和内容的所有更改:-)。主要缺点是，每次进行更改时，整个文档都会再次提交（不仅仅是更改）。但是考虑到文本文档通常不会很大，并且空间可能不是您的主要问题，这没问题。

我确定您可以在不使用Tortoise的情况下使用docdiff，这只是我没有尝试过。

您应该讨论另一种方法：BDD

请考虑具有可执行规范的行为驱动开发。您的规范将简化为一系列“给定-时间-然后”存储在文本文件中的语句集。诸如Cucumber或SpecFlow之类的BDD工具会将这些文本文件转换为可执行的测试，您的构建工具可以执行这些测试。

黄瓜： http ://cukes.info/-Ruby的BDD

SpecFlow：http： //www.specflow.org/-用于.Net的BDD

要使用SpecFlow之类的工具快速演示工作流程，请查看Rob Conery的SpecFlow演练：http : //tekpub.com/view/concepts/5

现在，不仅要对代码进行版本控制，还需要对规范以及持续集成工具（例如TeamCity，CruiseControl，Hudson等）进行版本控制，以确保所有规范在每次构建时都仍然有效……这对您有价值吗？