我应该如何处理 CVS 托管项目以 (1) 修复错误并 (2) 维护我自己的具有附加功能的私有分支
问题
一个开源程序使用 CVS 进行版本控制。我想修复一些错误并向具有提交访问权限的开发人员提交补丁炸弹。我还想维护我自己的半私有分叉，它主要跟踪主代码库，但包括我自己的功能（这些功能现在不应该合并到主代码库中。）
我更喜欢使用 Mercurial满足我自己的版本控制需求，但如果有必要，我愿意接受其他版本控制系统。
我希望：
- 能够通过我自己的错误修复轻松地针对当前的 CVS 源创建补丁炸弹
- 跟踪我自己的功能的历史记录 将主树中
- 地合并到我的新功能分支中
- 的修复和改进轻松 将我自己的错误修复应用到我的新功能分支中
- 能够在没有互联网连接的情况下工作和跟踪更改历史记录。
您对此有什么建议？
我目前的想法
下面是我自己的最佳猜测，以便让您更好地了解我的想法。
我将有 3 个 Mercurial 存储库。
前两个存储库按照 (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS) 中的指定进行管理。其仅反映来自 CVS 上游的最新更改。我在此存储库中执行“cvs update”然后“hg commit”。第二个存储库将我的错误修复保存为使用 mq 扩展的补丁，我从第一个存储库中提取并经常重新构建我的补丁。当我的补丁合并到主树中时，我从补丁队列中删除补丁/使它们永久提交。
第三个仓库是我的本地分支。它将作为第一个存储库的克隆开始。然后，每次更新第一个存储库时，我都会将其拉入存储库 3。我自己的功能将直接作为此存储库中的提交呈现。当我修复错误时，我将从存储库 2 导出补丁并将其应用到存储库 1 的相应拉取中。
The question
An open source program uses CVS for version control. I would like to make a number of bug-fixes and submit patch bombs to the developers with commit access. I would also like to maintain my own semi-private fork that mainly tracks the main code-base but that includes my own features (these features, right now, should not be incorporated into the main code-base.)
I prefer to use mercurial for my own version control needs, but I am open to other version control systems if necessary.
I'd like to:
- Be able to easily create patch-bombs against the current CVS source with my own bug-fixes
- Keep track of history on my own features
- Have fixes and improvements from the main tree easily incorporated in my new-feature fork
- Easily apply my own bug-fixes to my new-feature fork
- Be able to work and track change history without an Internet connection.
What suggestions do you have for doing this?
My current idea
My own best guess is below, to give you a better idea of what I am thinking about.
I will have 3 mercurial repositories.
The first two repos are managed as specified at (https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS). One just mirrors the latest changes from the CVS upstream. I do "cvs update" then "hg commit" in this repo. The second repo holds my bug-fixes as patches using the mq extension and I pull from the the first repo and re-base my patches every so often. When my patches are incorporated into the main tree, I remove the patches from the patch queue/make them permanent commits.
The third repo is my local fork. It will start out as a clone of the first repo. Then each time I do an update of the first repo, I'll pull from it into repo 3. My own features will be directly present as commits in this repo. When I fix a bug, I'll export a patch from repo 2 and apply it to the appropriate pull from repo 1.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我已经使用 Git 以类似的方式管理 CVS 存储库上的更改。我在 Git 中的解决方案使用本地分支而不是多个存储库，但这听起来与您提出的想法基本相似。
我发现，如果您将所有 CVS 元数据（在
CVS/子目录中）提交到镜像存储库，这种安排效果最佳。这意味着 CVS 元数据会复制到其他存储库中，但不会造成任何损害（如果需要，您可以运行cvs diff等命令）。I have used Git to manage changes on top of a CVS repository in a similar way. My solution in Git uses local branches instead of multiple repositories, but it sounds essentially similar to your proposed idea.
I found that this arrangement works best if you commit all the CVS metadata (in the
CVS/) subdirectories) to your mirrored repository. This means that the CVS metadata gets replicated in the other repositories, but it doesn't cause any harm (and lets you run commands likecvs diffif you need to).