views:

63

answers:

1

A subversion repository contains the html, latex and man directories that doxygen generates from the source code. Even for small source code changes, new files are being generated with random names which makes for large changes in the version control system.

Is there are way around this? How can I minimize the changesets between revisions while still including doxygen-generated documentation? Alternatively, how could I find which of the doxygen-genrated files are no longer being used and should be removed?

+3  A: 

I hate to answer a question without providing an answer to the specific question, but its generally a bad idea to track doxygen docs in your repository. The same thing holds true for autoconf generated configure scripts.

If you are worried about people not being able to generate the docs due to a lack of doxygen, its better to host them in their own private repo in your language and locale of choice.

You could modify build scripts to do this for you, with not too much effort. In my experience after working on free/open source software for a number of years, those who actually care about the docs will be able to generate them.. but your mileage may vary.

Eliminating redundant merge conflicts (i.e. Joe changed the comments AND the docs and now has to merge both) IMHO justifies externalizing the generated docs.

Tim Post
Fair point. I could just say fsck it and include only the pdf generated from the doxygen-created latex sources. OTOH having the html tree to browse is nice.
Dirk Eddelbuettel
how abuot a zip of the html, less files to merge at least. :)
Marcus Lindblom
Quite; but it's enough to have the html tree on a network drive. You don't have to put it under version control. Use an automated build server to keep these files current.
Aaron Digulla
@Marcus Lindblom: the fewer binary blobs that rest under the scope of the VCS, the faster it does things like bisect, diff against another revision, etc.
Tim Post
Aaron,tinkertim: Thanks, this is emerging as an idea. The source actually ends up as a tar.gz on a mirror network (CRAN, for the R language) but it is true that I could continue to generate doxygen files, and to ship them inside the tar.gz ... yet start to exclude them from the repo to minimize the 'line noise on changes'. Thanks!
Dirk Eddelbuettel
@Dirk Eddelbuettel: That would be the way to go. Its going to prevent far more headaches than it solves, prevention is better than a cure.
Tim Post