版本控制javadoc的优点和缺点

Dun*_*ril 6 version-control javadoc process

我想知道是否将Javadoc文件提交到我的项目的SVN存储库.

我已经阅读了有关SVN良好实践的内容,包括有关SO的一些有趣问题,但是没有一个专门针对javadoc处理问题.

起初我同意只有源代码应该被版本化的论点,并且我认为javadoc 非常容易用Eclipse重新构建,或者javadoc.xml例如来自ant文件,但我也想到了以下几点:

  • Javadoc文件是轻量级的,文本编码的,并且可以使用diff工具轻松跟踪对这些文件的更改.
  • 轻松跟踪javadoc的更改似乎很有趣,因为在"公共"javadoc的情况下,它的任何更改都可能意味着API的更改.
  • 愿意查看javadoc的人不一定想要获得整个项目并对其进行编译,因此将其放入repo似乎是另一个允许有效共享/跟踪的好主意.

你对此有何看法?请用建设性的,非主观的论点回答.我有兴趣了解哪些案例场景鼓励Javadoc的版本化,这使它看起来是一个糟糕的选择.

Nic*_*ver 4

反对的一个论点是合并冲突,作为一名前 SVN 用户,我讨厌与 SVN 合并。即使使用 Git,这也只是发生这些问题时要做的另一个工作步骤。如果您在一个更大的团队中,定期合并就是日常工作。

另一个反对的论点是,如果有些人不想要整个源代码树,请将整个项目放在像 Hudson 这样的 CI 系统下,并定期触发 javadoc 的创建,例如提交并将它们发布到某个地方。

我的结论是:不要对 javadocs 进行版本控制。