在RCS中使用文件夹

Question

我一直在学习关于如何使用RCS处理文件的教程http://www.burlingtontelecom.net/~ashawley/rcs/tutorial.html。这很好，但只适用于一个文件。是否也有一种方法可以创建包含目录的RCS文件？

我有一个名为myproject的项目文件夹，在这个目录中我有该项目的所有文件。我想为myproject文件夹及其内的所有文件创建一个修订控制系统。

Answer 1

正如William的评论所指出的，RCS只适用于单个文件。(它似乎也不适合多用户使用。)

当然，没有什么可以阻止您将每个(源文件)文件放在RCS控制下的目录中；实际上，CVS实际上就是这样做的(尽管在最近的版本中，它自己处理RCS数据，而不是像以前那样调用RCS来完成它)。不幸的是，这很严重地破坏了更改历史；影响到许多文件的提交最终成为对每个文件的单独提交，而这些文件恰好具有相同的提交消息(以及时间戳？)，而且一般来说，每个文件都会有不同的版本，用户可能会认为它是“相同的”修订。(这使得标记非常重要。)CVS还存在提交原子性的问题:您可能会被提交A和提交B纠缠在一起，因此在文件foo中提交A先于提交B，但在bar中提交B先于提交A！

SVN (Subversion)试图纠正CVS中的一些问题，尽管它也带来了一些新的限制，并保留了许多现有的问题；可能更明智的做法是(正如William所暗示的那样)只在您的多文件项目中使用分布式版本控制系统(DVCS)。有许多选择：

• 暗黑族使用了一个独特的基于补丁的模型:存储库被看作是一个补丁序列，可以应用于一个空树来构建当前的修订；补丁通常可以通过“交换”补丁对重新排序，而从其他存储库中挑选补丁是非常容易的。缺点是，变化历史比大多数DVCSes都不太清楚。见http://wiki.darcs.net/Using/Model，理论。
• 基于有向无环图(DAG)的DVCSes模型是一个存储库，它是一个有向无环的修订图，其中每个修订可以有一个父、两个父，或者更多。每个修订都有一个关联的文件树状态；有时重命名也会以某种方式被跟踪。
  • 正如前面提到的，Git。有一个非常简单的模型，但是一个非常复杂的接口:有许多命令，其中有些命令实际上并不适合人类使用(可能是因为其中的许多部分已经在shell脚本中原型化了)，所以很难找到您想要的命令。而且，它的模型可能有点过于简单:它根本不跟踪重命名。
  • 巴扎 (a.k.a.bzr)有一个更复杂的模型，包括对文件/目录重命名的支持。不过，很难说有多复杂，因为可能存在的任何文档都不如Git的那么容易访问。然而，它的用户界面确实要简单得多，还有许多有用的插件，包括一个分布式开发友好的SVN插件:从分支到SVN的提交不需要干扰其他分支分支的有效性，bzr元数据甚至被提交回SVN。如果您想在没有提交访问权限的情况下开始对基于SVN的项目进行黑客攻击，那么事情就不会那么痛苦了，但是希望最终能够提交您的更改。Bazaar是我个人最喜欢的基于DAG的DVCS。
  • 汞 (a.k.a.hg)似乎与Bazaar相当相似，尽管我认为它只跟踪单个文件而不是目录的重命名。它也支持插件，尽管它的SVN插件不如Bazaar的好:它不支持无损提交，因此从其他人的分支分支是不明智的。我没有太多的经验，所以我不能对它进行深入的评估.

​

Answer 2

正如注释中已经提到的，如果您从版本控制开始，您最好选择一个比RCS更新的系统(git、mercurial、fossil、subversion、.)。尽管如此，对于主要在一台机器上工作的单个开发人员来说，RCS仍然很好--我仍然将其用于我自己的代码，因为我还没有想出如何以我想要的方式将我想要的(20+多年)历史导入到git中。

无论如何，要使用RCS，请确保在每个目录中都有一个RCS子目录，在每个目录中都有RCS管理下的工作源代码。RCS文件将自动放置在子目录中，并自动检索.如果您的版本的make还没有意识到RCS，那么您可以对它进行培训，使其达到-或者获得一个版本的Make做(例如，GNU)。

Answer 3

TL:DR -看看DCVS，寻找一个替代的RCS。它使用CVS，它使用RCS，但它更适合在分布式存储库中工作，并且具有目录层次结构。

我目前正在经历一个类似的问题，并且可能已经发现了一些值得注意的东西，特别是对于那些被迫使用基于轻量级、基于命令行的修订控制系统和多个团队成员的人。

我的经理不会放弃使用RCS作为版本控制的想法。但是对于规范，他希望开发人员能够在我们公司的本地化服务器上创建和编辑自己的存储库。这方面有两个问题：

1. RCS不创建，也不保存任何类型的“存储库”。这是一个软件，跟踪文件编辑，在每个文件的基础上。这意味着“存储库”只不过是另一个具有RCS签入文件的目录。至少可以说，对于以团队为导向的项目来说，这是不够的。
2. 在一个具有多个目录和数十个单独工作文件的大型项目上，即使是在工作目录中创建一个具有符号链接的顶级RCS目录的前景也会引起复杂的问题，例如命名约定，以及忘记哪个文件来自哪个底层/工作目录。

使用SamB发布的内容，即使是CVS也会给出更多的问题，我们现在必须解释这些问题，但也给了我们一些额外的层次结构的能力。但他忘了的一个建议是DCVS。

它不过是CVS、CVSup的一个扩展，并且：

包含使用本地开发行分发CVS存储库的功能，并在后台自动处理分布式存储库的同步。