Hi,
Is there a consensus on this topic, agreeing to not committing Forrest
generated documentation ?
If we are still committing the Forrest output, I had another question.
One of the patches I was trying to commit changed documentation. When I
generated documentation, I found that all html and pdf files were
modified. A random check on a few HTML files showed that the change was
because the Hadoop version was changing.
For e.g.
Index: docs/hdfs_permissions_guide.html
===================================================================
--- docs/hdfs_permissions_guide.html (revision 727963)
+++ docs/hdfs_permissions_guide.html (working copy)
@@ -69,7 +69,7 @@
<a class="unselected" href="http://wiki.apache.org/hadoop";>Wiki</a>
</li>
<li class="current">
-<a class="selected" href="index.html">Hadoop 0.20 Documentation</a>
+<a class="selected" href="index.html">Hadoop 0.21 Documentation</a>
</li>
</ul>
Should I commit all the files, or only the ones that the patch touches ?
Thanks
Hemanth
Nigel Daley wrote:
+1 for (1).
On Dec 1, 2008, at 12:54 PM, Doug Cutting wrote:
We currently re-generate PDF and HTML documentation whenever we
commit a documentation patch, which creates huge commit messages that
few read. This was originally done so that folks who check out the
sources from subversion did not need to install forrest in order to
read the documentation.
Perhaps we should change this. Some options:
1. Do not commit Forrest output at all. Documentation would be
generated as a part of release builds, or when a developer wanted to
browse it, just as javadoc is. Documentation on the website would be
extracted from the release tarball, just as javadoc is.
2. Do not commit Forrest output except when preparing for a release.
3. Keep committing Forrest output each time a documentation change is
made.
(I'm speaking here about the versioned documentation, that's included
in releases, not the project website, which we commit for a different
reason--so that ops can quickly rebuild it--and that changes more
slowly.)
My preference would be for (1). Thoughts?
Doug
