2

我一直在关注教程http://www.burlingtontelecom.net/~ashawley/rcs/tutorial.html关于如何使用 RCS 处理文件。这很好用，但只有一个文件。有没有办法创建带有目录的 RCS 文件？

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

4

3 回答 3

3

正如威廉的评论所说，RCS 仅适用于单个文件。（它似乎也不是特别适合多用户的东西。）

当然，没有什么能阻止您将每个（源）文件放在 RCS 控制下的目录中。事实上，这本质上就是 CVS 所做的（尽管在最近的版本中，它自己处理 RCS 数据，而不是像以前那样调用 RCS 来做）。不幸的是，这严重破坏了变更历史。影响许多文件的提交最终会作为对每个文件的单独提交，这些文件恰好具有相同的提交消息（和时间戳？），并且通常每个文件都会有不同的修订版本，用户可能会认为是“相同”的修订。（这使得标签非常重要。）CVS 还存在提交的原子性问题：您最终可能会导致提交 A 和提交 B 纠缠在一起，这样在文件中foo提交 A 在提交 B 之前，但在文件中bar提交 B 在提交 A 之前！

SVN (Subversion) 是对 CVS 中一些问题的一种尝试，虽然它也带来了一些新的限制，但保留了许多现有的限制；为您的多文件项目使用分布式版本控制系统 (DVCS) 可能更明智（正如 William 暗示的那样）。有很多选择：

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

正如评论已经提到的，如果您从版本控制开始，建议您选择比 RCS 更新的系统（git、mercurial、fossil、subversion，...）。也就是说，对于主要在单台机器上工作的单个开发人员来说，RCS 仍然可以正常工作 - 我仍然将它用于我自己的代码，因为我还没有确定如何获得我想要的（20 多年的）git历史我想要的方式。

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

于 2011-03-14T18:04:53.463 回答
1

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

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

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

  1. RCS 不创建也不持有任何类型的“存储库”。它是基于每个文件跟踪文件编辑的软件。这意味着“存储库”只不过是另一个包含 RCS 签入文件的目录。至少可以说，这对于团队导向的项目来说是低于标准的。

  2. 在具有多个目录和数十个单独工作文件的大型项目中，即使是在工作目录中创建带有符号链接的顶级 RCS 目录也会导致复杂性，例如命名约定，以及忘记来自哪个文件哪个底层/工作目录。

根据 SamB 发布的内容，即使 CVS 也给我们现在必须解决的 RCS 带来了额外的问题，但给了我们一些额外层次结构的能力。但他忘记的一个建议是DCVS。

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

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

于 2018-03-21T15:42:39.857 回答