版本控制 – 版本控制javadoc的优缺点

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

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

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

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

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

解决方法

反对一个论点是合并冲突,作为一个以前的SVN用户,我讨厌与SVN合并.即使使用 Git,如果出现这些问题,这只是另一个工作步骤.如果你在一个更大的团队定期合并是日常工作.

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

对我来说,Conclusio是:不要版本javadocs.

相关文章

最近看了一下学习资料,感觉进制转换其实还是挺有意思的,尤...
/*HashSet 基本操作 * --set:元素是无序的,存入和取出顺序不...
/*list 基本操作 * * List a=new List(); * 增 * a.add(inde...
/* * 内部类 * */ 1 class OutClass{ 2 //定义外部类的成员变...
集合的操作Iterator、Collection、Set和HashSet关系Iterator...
接口中常量的修饰关键字:public,static,final(常量)函数...