长 CVS 版本号有任何技术问题吗？
我们的项目有从现有分支在 CVS 中创建新分支的历史。几年后，这导致了每个版本中更改的文件的这种情况：
新修订版：1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6 .2.23;
以前的版本：1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.22
显然这在 CVS 控制台中看起来很糟糕，但这在技术上真的很重要吗？通过将所有内容合并回头部，使其回到 1.146，我们会得到什么吗？
（PS“切换到颠覆”不是答案。）
Our project has a history of creating new branches in CVS from existing branches. After several years, this has led to this situation on the files that are changed in every release:
new revision: 1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.23;
previous revision: 1.145.4.11.2.20.2.6.2.20.2.1.2.11.2.3.2.4.4.4.2.5.2.1.2.1.2.6.2.22
Obviously this looks bad in the CVS console, but does it actually matter technically? Would we gain anything by merging everything back to the head so it is back at 1.146?
(P.S. "Switch to subversion" is not an answer.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
显然，这已经为您工作了好几年了，所以如果存在技术问题，那么您还没有看到它们。我不知道你会遇到什么；然而，如果这种情况在未来几年持续下去，如果您开始发现各种工具的限制和错误，我不会感到惊讶。 （更不用说您永远无法满足源代码行长度准则。:P）
清晰度。即使更复杂的系统在技术上是合理的，更简单的系统也更容易使用。合并回 1.146 会有什么损失吗？此时，您正在谈论特定于项目和特定组的收益，其价值会有所不同，您只需决定付出的努力是否值得结果。
Obviously, this has worked for you for several years, so if there are technical problems, then you've not yet seen them. I don't know of any that you'll run into; however, if this continues over the next several years, I would not be surprised if you start to find limits and bugs in various tools. (Not to mention you can't ever meet source code line-length guidelines. :P)
Clarity. A simpler system is easier to work with, even if the more complex equivalent is technically sound. Do you have anything to lose by merging back to 1.146? At this point, you're talking about project- and group-specific benefits whose value will vary, and you'll just have to decide if the effort is worth the result.
对于合并有一些争论：
方便——引用较短的修订号比引用长得离谱的修订号更容易。但按编号引用 CVS 修订版的情况并不常见，因为各个文件的修订版号并不统一，因此这种优势很小。
性能——CVS 存储修订增量的方式针对处理 HEAD 顶端的修订进行了优化（请参阅 rcsfile(5)）。如果检查和其他 CVS 操作所需的时间变得难以忍受，将开发主线合并回 HEAD 可能会有所帮助。
避免工具错误——您正在使用的某些工具（CVS？提交通知工具？Web 查看器？IDE 插件？）很可能对其可以处理的修订号大小有内置限制。如果您遇到此类错误，无论您愿意与否，您都可能被迫改变自己的风格。
但是合并有一些您不应该忘记的重大缺点：
鉴于 CVS 不记录有关合并的信息，将开发重新合并意味着丢失导致新的“当前”版本的修订历史记录。例如，
cvs log将不再告诉您导致当前修订的更改顺序。除非你改变你的开发流程，否则你的代码库将再次开始枝繁叶茂，使任何收益都是暂时的。 （相反，如果你打算同时改变你的开发流程，那么重新合并会更合理。）
当（我敢说，不可避免的）时间到来时，您决定从 CVS 迁移到更现代的版本控制系统，正确的历史记录（没有假合并）可能会更容易让迁移工具理解。
总而言之，我建议坚持您当前的做法，直到您遇到的具体问题超过合并回 HEAD 的缺点为止。
There are a few arguments for merging:
Convenience -- It is easier to refer to shorter revision numbers than to absurdly long ones. But it is unusual to refer to CVS revisions by number, because revision numbers are not uniform across files, so this advantage is minor.
Performance -- The way that CVS stores revision deltas is optimized for dealing with the revision at the tip of HEAD (see rcsfile(5)). If the time required for checkouts and other CVS operations is getting intolerable, merging the main line of development back to HEAD might help.
Avoiding tool bugs -- It is quite plausible that some tool that you are working with (CVS? Commit notification tools? Web viewer? IDE plugin?) has built-in limits to the size of revision numbers that it can deal with. If you encounter such bugs, you might be forced to change your style whether you want to or not.
But there are a few significant disadvantages of merging that you should not forget:
Given that CVS doesn't record information about merges, merging development back to head would mean losing the history of revisions leading to the new "current" version. For example,
cvs logwill no longer tell you the sequence of changes that led to the current revision.Unless you change your development process, your code base will start sprouting branches-on-branches again, rendering any gains temporary. (Conversely, if you plan to change your development process at the same time, merging back to head would be more justifiable.)
When the (dare I say, inevitable) time comes when you decide to migrate away from CVS to a more modern version control system, the correct history (without fake merge) will probably be easier for the migration tool to make sense of.
All in all, I would recommend sticking with your current practice until you have concrete problems that outweigh the disadvantages of merging back to HEAD.
CVS 的大小限制可能取决于您选择使用的 CVS 的具体实现。该特定应用程序将设置版本号的最大字符串大小。我无法想象它会比 50 或 100 高很多，但这不是重点。尽管您可能可以避免使用如此长的版本号字符串，但这并不可取。
如果版本号太长，人们阅读和理解会很困难。您应该考虑使用更短、更简洁的版本来传达相同的含义。
由于小数点后的每个数字都表示更改重要性的级别，因此实际上最多只需要 4 或 5 个周期。否则，这表明您的软件构建周期太长，或者您只是滥用版本号约定。我最多会坚持 4 或 5 个周期。
它应该是这样的：<主要版本>.<版本的半主要版本>.<发布版本>.<内部版本号>，如果您正在使用产品版本 4，这会导致类似于 4.2.12.45 的内容（这几乎就是你向用户展示的内容），这是第二个大版本，因为 4 的工作方式发生了重大变化，但它仍然像 4 应该工作的那样工作，并且第 12 个版本修复了错误、安全性最后是第 45 个开发版本，同时在 4.2.12 发布之前进行测试。这只是一个例子，但是这样的东西效果很好。
The size limit for CVS would probably depend on the specific implementation of CVS you have chosen to go with. That particular application would have set the maximum string size for the version number. I can't imagine it would be much higher than 50 or 100, but that's not the point. Although you could probably get away with having such a long version number string, it is not advisable.
If the version number is too long it will be very difficult for people read and understand. You should consider using a shorter, more condensed version which will convey the same meaning.
Since each number after a decimal point signifies a level of change significance, you should really only need 4 or 5 periods max. Otherwise, it is an indication that your software build cycles are TOO LONG or you are just abusing the version number conventions. I would stick with 4 or 5 periods, max.
It should go something like this: <major version>.<semi major release of version>.<release version>.<build number>, which leads to something like 4.2.12.45 if you are working on product version 4 (which is pretty much what you show to the user), and it was the second big release because there were significant changes to how 4 works, but it still works like 4 was supposed to work, and the 12th version with bug fixes, security updates, etc. And finally the 45th development build while doing testing before the release of 4.2.12. This is just an example, but something like this works very well.