版本控制系统和Subversion

我曾答应在我关于数字化和编辑数字的帖子但一直没能抽出时间。最近一连串的请求下载Uintah让我想起了我的诺言。故事是这样的。

考虑以下情况。现在是一月份，你开始写一段代码。经过大量的调试和测试后，您最终确定它是有效的。你运行了大量的模拟并公布了结果。在6月，您决定在您的模型中有几个改进需要合并到您的代码中。您解决了所有问题，并开始修改代码。为了安全起见，您保留了原始工作代码的副本。最初的几个小改变就像一种魔力。然后你做了一个你认为很小的改变，却发现整个代码都坏了。因此，您开始注释部分，以找出是什么破坏了代码，直到您到达(您认为是)1月份的版本。 But the code still does not work. After several days of frustration you find that you forgot to comment out two extra lines and finally get the code to work. Now you have to work forward and incorporate the new changes again and so on ....

很久以前，软件工程师们就认为记录代码中的变化应该是自动化的。结果是源代码控制系统(SCCS)．这里有一个关于我在SCCS的经历的故事。1994年，我接到了库德雷穆克(印度南部一个美丽的山城)的一位客户的紧急电话。我们的地质统计代码不起作用，这影响了他们的生产计划。我带着我们最新版本的代码(以直径1英尺的磁带和一对6英寸的盒式磁带的形式)飞了下来。客户的代码版本是三年前的。此外，Kudremukh代码中还有几个额外的功能已经从主版本中删除。我必须在一周内让代码运行起来。幸运的是，我们的代码保存在SCCS存储库中。我找到了客户代码的版本，并从我的磁带中检查了那个版本。 A comparison of the file sizes in the customer's version and my SCCS version showed that a few files were different. After that it took me less than an hour to figure out the problem and fix it. Had I not had SCCS it would have taken me several days to find the problem.

然而，到1995年，SCCS几乎已经过时，取而代之的是一种更好的系统，称为版本控制系统(RCS)．RCS有一些与SCCS相同的问题，即一次只能控制一个文件，并且需要额外的脚本来同时管理大量文件。RCS几乎立即被并发版本系统(CVS)这使得处理大型项目更加容易。即使在今天，CVS也被广泛用于源代码控制。

2001年，CVS的一个开源替代品叫做Subversion (SVN)开始流行起来。我们在2002年左右将我们的ubuntu代码从CVS移到了SVN。Subversion与大多数Linux发行版捆绑在一起，也可以从中下载http://subversion.tigris.org/．SVN存储库易于设置和使用。一个好的起点是针对非程序员的Subversion版本控制基思·菲尔德豪斯著。

版本控制不仅仅是针对程序员的。我用它来处理提案、论文、数据和许多其他类型的文件。尝试一下，你将永远不会回到手动维护无数个文档副本的状态。