使用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中的一些问题，虽然它也带来了一些新的局限性，并保留了许多现有的局限性;对于您的多文件项目来说，使用分布式版本控制系统（DVCS）可能更为明智（正如威廉所暗示的那样）。有很多选择：

• Darcs使用基于补丁的独特模型：存储库被视为一系列补丁，可以应用于空树以构建当前版本;通常可以通过“通勤”修补程序对修补程序进行重新排序，而从其他存储库中挑选修补程序非常容易。缺点是变化历史比大多数DVCS更不清楚。请参阅http://wiki.darcs.net/Using/Model，http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory。
• 基于定向非循环图（DAG）的DVCS将存储库建模为修订的有向非循环图，其中每个修订版可以有一个父级，两个父级或者更多。每个修订都有一个关联的文件树状态;有时也会以某种方式跟踪重命名。
  • Git，如前所述。有一个非常简单的模型，但是一个非常复杂的界面：有许多命令，其中一些并不是真正供人类使用的（由于它的许多部分可能已经在shell脚本中原型化），所以它可能很难找到你想要的。此外，它的模型可能有点太简单：它根本不跟踪重命名。
  • Bazaar（a.k.a。bzr）有一个更复杂的模型，包括对文件/目录重命名的支持。但是，很难说有多复杂，因为可能存在的任何文档都不像Git那样容易访问。但它确实有一个相当简单的用户界面，并且有许多有用的插件，包括一个支持分布式开发的SVN插件：从分支机构返回到SVN不需要干扰其他分支机构的有效性。分支和bzr元数据甚至被提交回SVN。如果你想在没有提交访问权限的情况下开始攻击基于SVN的项目，可以减少痛苦，但希望最终能够实现你的更改。 Bazaar是我个人最喜欢的基于DAG的DVCS。
  • Mercurial（a.k.a。hg）似乎与Bazaar非常相似，不过我认为它只跟踪单个文件的重命名，而不是目录。它也支持插件，虽然它的SVN插件不如Bazaar那样好：它不支持无损提交，因此从其他人的分支分支是不明智的。我没有太多的经验，所以我无法深入评估它。

Answer 2

TL：DR - 查看DCVS以获取RCS的替代方案。它使用CVS，它使用RCS，但它更加模块化，可以在分布式存储库中工作，并具有目录层次结构。

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

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

1. RCS不会创建，也不会拥有任何类型的“存储库”。它是在每个文件基础上跟踪文件编辑的软件。这意味着'存储库'只不过是具有RCS签入文件的另一个目录。至少可以说，这对于团队合作的项目来说是次要的。

2. 在一个包含多个目录和数十个单独工作文件的大型项目中，甚至在工作目录中创建带有符号链接的顶级RCS目录的前景也会导致命名约定等复杂问题。忘记哪个文件来自哪个底层/工作目录。

随着SamB发布的内容，即使是CVS也会给我们现在必须考虑的RCS带来额外的问题，但是我们可以为一些额外的层次结构提供一些能力。但他遗忘的一个建议是DCVS。

它只不过是CVS，CVSup和

的扩展

  

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

Answer 3

正如评论已经提到的，如果您开始使用版本控制，建议您选择比RCS更新的系统（git，mercurial，fossil，subversion，...）。也就是说，RCS仍适用于主要在一台机器上工作的单个开发人员 - 我仍然将它用于我自己的代码，因为我还没有找到如何获得我想要的（20多年）历史{ {1}}就像我想要的那样。

无论如何，要使用RCS，请确保在RCS管理下具有工作源代码的每个目录中都有一个RCS子目录。 RCS文件将自动放置在子目录中，并自动检索。如果您的git版本尚未了解RCS，那么您可以对其进行训练 - 或者获取make版本（例如GNU Make）。