我们的项目有从现有分支机构在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吗？
（P.S。“切换到颠覆”不是答案。）
答案 0 :(得分：3)
显然，这对你来说已经有好几年了，所以如果有技术问题，那么你还没有看到它们。我不知道你会遇到什么;但是，如果这种情况在未来几年持续下去，如果您开始在各种工具中找到限制和错误，我不会感到惊讶。 （更不用说你不能满足源代码行长准则。：P）
我们可以通过将所有东西合并到头部来获得任何东西，以便它回到1.146吗？
<强>净度即可。更简单的系统更易于使用，即使更复杂的等效技术在声音上也是如此。合并回1.146会有什么损失吗？在这一点上，您谈论的是项目和群体特定的利益，其价值会有所不同，您只需要决定努力是否值得结果。
答案 1 :(得分：1)
我们可以通过将所有东西合并到头部来获得任何东西，以便它回到1.146吗？
合并有一些论据：
便利性 - 引用较短的修订号而不是荒谬的修订号更容易。但是，按编号引用CVS修订是不常见的，因为修订号在文件之间并不统一，因此这种优势很小。
性能 - CVS存储修订版增量的方式已针对处理HEAD顶端的修订进行了优化（请参阅rcsfile（5））。如果结账和其他CVS操作所需的时间变得无法忍受，将主要开发项目合并回HEAD可能会有所帮助。
避免工具错误 - 您正在使用的某些工具（CVS？提交通知工具？Web查看器？IDE插件？）内置限制版本号的大小是非常合理的可以处理。如果你遇到这样的错误，你可能会被迫改变自己的风格。
但合并有一些明显的缺点，你不应该忘记：
鉴于CVS没有记录有关合并的信息，将开发合并到头部将意味着丢失导致新“当前”版本的修订历史。例如，cvs log将不再告诉您导致当前修订的更改顺序。
除非您更改开发过程，否则您的代码库将再次开始分支分支，从而使任何收益暂时增加。 （相反，如果你打算同时改变你的开发过程，合并回头会更合理。）
当您决定从CVS迁移到更现代的版本控制系统时（我敢说，不可避免）时间到来时，正确的历史记录（没有伪合并）可能会更容易迁移工具理解。
总而言之，我建议坚持你现在的做法，直到你遇到的具体问题超过合并回HEAD的缺点。
答案 2 :(得分：0)
CVS的大小限制可能取决于您选择使用的CVS的具体实现。该特定应用程序将设置版本号的最大字符串大小。我无法想象它会高于50或100，但这不是重点。虽然你可能会因为拥有如此长的版本号字符串而侥幸成功，但这是不可取的。
如果版本号太长，人们很难阅读和理解。您应该考虑使用更短，更精简的版本，这将传达相同的含义。
在某些方案中，基于序列的标识符用于表示版本之间变化的重要性：变更按重要性级别进行分类，并且决定在版本之间更改哪个序列是基于之前更改的重要性释放，其中第一个序列针对最显着的变化而改变，并且在第一个序列之后的变化表示降低显着性的变化。 [维基百科的Software versioning]
由于小数点后面的每个数字表示变化显着性水平，因此您最多只需要4或5个句点。否则，表明您的软件构建周期太长或者您只是滥用版本号约定。我坚持4或5个时期，最多
它应该是这样的：＆lt;主要版本＆gt;。＆lt;版本的主要版本＆gt;。＆lt;发布版本＆gt;。＆lt;内部版本号＆gt;，如果您正在处理，则会导致4.2.12.45之类的内容产品版本4（这几乎是你向用户展示的），它是第二个大版本，因为4如何工作有重大变化，但它仍然有效，4应该工作，第12版有bug修复，安全更新等。最后是第45个开发构建，同时在4.2.12发布之前进行测试。这只是一个例子，但是这样的事情很有效。