No, the htdocs repository has been set up like that intentionally long before I got involved in the GnuCash project.

The htdocs repo is a bit of a special case: it's not only set up to manage the changes made to the website, but also to automatically trigger an update of the live website each time the svn repo is changed.

The website also hosts the released documentation in various formats, html, pdf, epub and mobi. Just as with the rest of the website's content, the established method of adding this documentation on the live website is by committing it into svn. The website update triggers take care from there on.

I believe this has been set up like this in the past because the website is hosted on a server managed by Linas and he is the only admin there. To avoid a dependency on his availability for the website updates, an automated system was setup based on an svn post-commit trigger to reuse a security mechanism that was already in place.

Having said all that, I do agree with you that this causes a lot of svn overhead for people that only want to update a website translation.

We may be able to refine this set up by splitting the website update logic from the documentation update logic. But there are some complications that we need to think through properly:
- the docs being hosted on the website are the build products from the gnucash-docs repo, not the source files from that repo. So simply syncing the gnucash-docs repository to the webserver is not useful. The gnucash-docs have to be generated somewhere and the generated files uploaded.
- given Linas is the only admin for the webserver, all webcontent should continue to be uploaded automatically. That goes both for the web content as for the generated docs. Currently the update happens based on a svn post-commit hook trigger. In the future this is likely to change into a git update trigger.

In my opinion though the best moment to look into this is when we switch from svn to git for the website repo. We have to revisit the whole post-commit logic anyway at that moment.

I see a split as follows:
- one repo for htdocs, but this time excluding the gnucash-docs.
- one repo in which we store the files built by gnucash docs (html, epub, pdf,...). If we follow our current publication scheme, this should happen only once for each documentation release. We could extend it though to also contain the files from nightly builds. This wasn't done so far so save bandwidth. We may evaluate if using a git repo to track changes will be saving us sufficient bandwidth to host all the documentation builds on the live webserver or not.

I'm not sure how to best organize the gnucash-docs build repo to be practical yet. From the repo point of view it would be most efficient if we had one documentation tree and each release would be a version of that tree (possibly tagged). From the webserver's point of view it will probably be easier if each version of the documentation would be a separate directory in the repo. The latter consumes much more space unfortunately.

The htdocs repo is the live website source, which includes the built documentation.  The website does not build the documentation.  The website contains a link to the daily builds of the docs (for Trunk) and a pre-built version of the docs (for the stable release).  Arguably it doesn't need the previous releases of the docs, but htdocs does need the built current stable docs.

Anno 2015, the website and the built docs are separate repositories. Time to close an old bug...

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=689904. Please update any external references or bookmarks.