如何使用 CVS 管理变更集？
过去几年我一直在使用分布式版本控制系统，但现在我将不得不使用 CVS。我想要的过程是这样的：
- 每个错误/功能都有一张票 在票务系统中，
- 开发人员被分配到 错误/功能（如有必要，请提供票证 将被分成更小的票 以便开发商开票 关系是一对一的）
- 开发人员进行更改并将其与票证相关联
- 在固定的时间点，一组 选择要发布的门票 候选人 发布候选人将 被测试
- 版本是使用以下子集构建的 来自候选者的票证
- ，循环再次开始
我当前的天真的计划是将
- 每个票证放在主干上自己的分支中，
- 为每个候选版本创建一个分支，
- 将票证分支合并到候选版本中
- 当候选版本被认为是好的时， 足够将它合并到主干中
我已经忘记了我以前所知道的有关 CVS 的所有内容，但我有一种直觉告诉我这将是一个错误。我会遇到什么性能问题或其他类型的问题？是否有更好的方法来根据给定时期内完成的工作子集有选择地创建构建？
I have been using distributed version control systems for the last few years, but now I am going to have to use CVS. The process I want is something like:
- Each bug/feature is given a ticket
in a ticketing system - A developer is assigned to a
bug/feature (if necessary a ticket
will be broken into smaller tickets
so that the developer to ticket
relationship is one-to-one) - The developer makes changes and associates them with the ticket
- At regular points in time a set of
tickets are chosen for a release
candidate The release candidate will
be tested - A release is built using a subset of
the tickets from the candidate - and the cycle starts again
My current, naïve plan is to
- put each ticket in its own branch off of the trunk
- create a branch for each release candidate
- merge the ticket branches into the release candidate
- when a release candidate is considered good enough merge it into the trunk
I have forgotten everything I used to know about CVS, but I have a gut feeling that tells me this is going to be a mistake. What performance or other types of problems am I going to run into? Is there a better way to selectively create builds based on a subset of the work done during a given period?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可以在本地使用分布式版本控制系统，并在功能准备好发布时发布到 CVS。
请参阅此问题：如何将修订历史记录从 Mercurial 或 git 导出到 cvs？
You could locally use a distributed version control system, and publish to CVS when a feature is ready for release.
See this question: How to export revision history from mercurial or git to cvs?