在 RCS 中使用文件夹
我一直在关注教程 http://www.burlingtontelecom.net/~ashawley/rcs /tutorial.html 了解如何使用 RCS 处理文件。这很有效，但仅适用于一个文件。有没有办法创建带有目录的 RCS 文件？
我有一个名为 myproject 的项目文件夹，在这个目录中我有该项目的所有文件。我想为 myproject 文件夹及其内部的所有文件创建一个版本控制系统。
I have been following the tutorial http://www.burlingtontelecom.net/~ashawley/rcs/tutorial.html on how to work with files using RCS. This works well but only with one file. Is there a way to create an RCS file with directories as well?
I have a project folder called myproject, and in this directory I have all my files for that project. I want to create a revision control system for the myproject folder and all its files that are inside.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如 William 的评论所说，RCS 仅适用于单个文件。 （它似乎也不是特别适合多用户的东西。）
当然，没有什么可以阻止您将每个（源）文件放入 RCS 控制下的目录中；事实上，这本质上就是 CVS 所做的事情（尽管在最近的版本中，它自己处理 RCS 数据，而不是像以前那样调用 RCS 来执行此操作）。不幸的是，这严重破坏了变更历史；影响许多文件的提交最终会作为对每个文件的单独提交，这些文件恰好具有相同的提交消息（和时间戳？），并且通常每个文件都会有不同的修订版本，用户可能会认为这是“相同”修订版。 （这使得标签变得非常重要。）CVS 还存在提交原子性问题：最终可能会出现提交 A 和提交 B 纠缠在一起的情况，例如在文件
foo中，提交 A 先于提交 B，但在文件bar中，提交 B 在提交 A 之前！SVN（Subversion）是纠正CVS中一些问题的尝试，尽管它也带来了一些新的限制，并保留了许多现有的限制；对于多文件项目使用分布式版本控制系统 (DVCS) 可能是更明智的做法（正如 William 所暗示的那样）。有很多选择：
bzr）有一个更复杂的模型，包括支持文件/目录重命名。不过，很难说要复杂多少，因为无论存在什么文档，都不像 Git 那样易于访问。然而，它确实有一个相当简单的用户界面，并且有许多有用的插件，包括分布式开发友好的 SVN 插件：从分支提交回 SVN 不需要干扰您的其他分支的有效性。分支，bzr 元数据甚至被提交回 SVN。如果您想在没有提交访问权限的情况下开始攻击基于 SVN 的项目，但希望最终提交更改，可以让事情变得不那么痛苦。 Bazaar 是我个人最喜欢的基于 DAG 的 DVCS。hg）看起来与 Bazaar 非常相似，但我认为它仅跟踪单个文件的重命名，而不跟踪目录的重命名。它还支持插件，尽管它的 SVN 插件不如 Bazaar 的好：它不支持无损提交，因此从其他人的分支分支是不明智的。我对此没有太多经验，所以无法真正深入地评估它。As William's comment says, RCS only works with single files. (It also doesn't seem to be particularly suitable for multiple-user stuff.)
Of course, nothing stops you from putting each (source) file in a directory under RCS control; in fact, this is essentially what CVS does (though in recent versions it handles the RCS data itself, rather than invoking RCS to do it as it used to do). Unfortunately, this fragments the change history rather badly; a commit affecting many files ends up as separate commits to each file, which just happen to have the same commit message (and timestamp?), and in general every file will have a different revision in what the user might like to think of as the "same" revision. (This makes tags quite essential.) CVS also has issues with the atomicity of commits: you could end up with commit A and commit B getting tangled up, such that in file
foocommit A precedes commit B, but in filebarcommit B precedes commit A!SVN (Subversion) is an attempt to rectify some of the problems in CVS, though it also brings some new limitations, and keeps many of the existing ones; it is probably wiser (as William implies) to just use a distributed version control system (DVCS) for your multi-file projects. There are many choices:
bzr) has a more complicated model, including support for file/directory renames. It's difficult to say how much more complicated, though, because whatever documentation may exist is not nearly as accessible as Git's. It does, however, have a rather simpler user interface, and there are a number of useful plugins, including a distributed-development-friendly SVN plugin: committing from a branch back to SVN need not interfere with the validity of others' branches of your branches, and bzr metadata is even committed back to SVN. Can make things much less painful if you want to start hacking on an SVN-based project without having commit access, but hope to get your changes committed eventually. Bazaar is my personal favorite DAG-based DVCS.hg) seems fairly similar to Bazaar, though I think it tracks renames only for individual files, not for directories. It also supports plugins, though its SVN plugin isn't as nice as Bazaar's: it doesn't support lossless commits, so branching from other peoples' branches is unwise. I don't have much experience with it, so I can't really evaluate it in-depth.TL:DR - 查看 DCVS 寻找 RCS 的替代方案。它使用 CVS，后者使用 RCS，但它更加模块化，适合在分布式存储库中工作，并且具有目录层次结构。
我目前正在经历类似的问题，并且可能发现了一些值得注意的事情，特别是对于那些被迫与多个团队成员一起使用基于命令行的轻型版本控制系统的人。
我的经理不会放弃使用 RCS 作为我们的版本控制的想法。但对于规范，他希望开发人员能够在我们公司本地化服务器上的自己的存储库上创建和编辑。有两个问题：
RCS 不会创建或保存任何类型的“存储库”。它是基于每个文件跟踪文件编辑的软件。这意味着“存储库”只不过是另一个包含 RCS 签入文件的目录。至少可以说，这对于团队项目来说是低于标准的。
在具有多个目录和数十个单独工作文件的大型项目中，即使是在工作目录中创建带有符号链接的顶级 RCS 目录，也会引起命名约定等复杂情况，以及忘记哪个目录文件来自哪个底层/工作目录。
根据 SamB 发布的内容，即使 CVS 也给我们现在必须考虑的 RCS 带来了额外的问题，但给了我们一些额外的层次结构的轻微能力。但他忘记了一个建议：DCVS。
它只不过是 CVS、CVSup 的扩展，并且：
TL:DR - Look into DCVS for an alternative of RCS. It uses CVS, which uses RCS, but it's more modular for working in a repository that is distributed, as well as having a hierarchy of directories.
I'm currently going through a similar issue, and may have found something worthy of note, especially for people who are being forced to use a light, command-line based revision control systems with multiple team members.
My manager will not get off this idea of using RCS as our version control. But for the specifications, he wants developers to be able to create and edit on their own repository on a localized server within our company. Two issues with this:
RCS does not create, nor hold any sort of 'repository'. It is software that keeps track of file edits, on a Per File Basis. Meaning that the 'repository' is nothing more than another directory with RCS checked-in files. This is sub-par for team-geared projects, to say the least.
On a large project with multiple directories and tens of individual working files, even the prospect of creating a top-level RCS directory with a symbolic link in the working directories gives rise to complications such as naming conventions, as well as forgetting which file came from which bottom-level / working directory.
With what SamB posted, even CVS gives additional problems with RCS that we now have to account for, but gives us a slight ability for some additional hierarchy. But one suggestion he forgot was DCVS.
It's nothing more than an extension of CVS, CVSup, and:
正如评论已经提到的，如果您开始使用版本控制，我们强烈建议您选择比 RCS 更新的系统（git、mercurial、fossil、subversion，...；在 2023 年，git 可能应该是默认选择）。也就是说，对于主要在一台机器上工作的单个开发人员来说，RCS 仍然工作得很好 - 我仍然将它用于我自己的代码，因为我还没有弄清楚如何将我想要的（20 多年的）历史记录放入
git以我想要的方式。无论如何，要使用 RCS，请确保在 RCS 管理下有工作源代码的每个目录中都有一个 RCS 子目录。 RCS 文件将自动放置在子目录中，并自动检索。如果您的
make版本尚不支持 RCS，那么您可以对其进行训练以使其支持 - 或者获取支持 RCS 的 make 版本（例如 GNU Make）。As the comments already mention, if you are starting out with version control, you would be well advised to choose a newer system than RCS (git, mercurial, fossil, subversion, ...; in 2023, git should probably be the default choice). That said, RCS still works fine for a single developer working primarily on a single machine - I still use it for my own code because I've not yet worked out how to get the (20+ years of) history I want into
gitin the way I want it.Anyway, to use RCS, make sure you have an RCS sub-directory in each directory where you have working source code under RCS management. The RCS files will be placed in the sub-directory automatically, and retrieved automatically. If your version of
makeis not already aware of RCS, then you can train it so that it is - or get a version of make that does (GNU Make, for example).