I am working on a personal project and although I do have a wiki I would like to add different documentation files to the svn repository. Such files include XML (generated by monodoc) as well as UML diagrams(generated with dia).
In this a good idea, I have hear/read comments about not adding binary data to the svn repo and try to just keep code, is that right???
I would add all documents, libraries and anything else to the repository. Basically anything that is relevant to the project because then everyone has access to it and will also have the latest version.
Subversion handles binary files just fine:
http://subversion.tigris.org/faq.html#binary-files
So if it makes sense to have these files in your source tree, I'd say check 'em in.
It's not about binary versus text, it's about whether it's generated or not. If you generate these things, why not add the source of the generation along with the tools to do the generation to SVN rather than the generated files themselves? Then, coupled with good build scripts (also in SVN), you can always regenerate them again. Otherwise, you run the risk of the generated files being out of sync with the source files, or of people treating the generated files as "masters" and having their changes confusingly overwritten.
HTH, Kent
I think it is perfectly ok to keep any files that can not be regenerated from the source files in SVN. That includes dia/xml documentation, and images.
Of course, it is probably better to prefer to store them as text where possible - so, better a CSV spreadsheet than an Excel file.
Add everything that has to do with the project. Adding binary (e.g. libraries) is no problem, but: avoid adding duplicated data, like files that are compiled from the source.
svn handles binary files just fine, but I wouldn't add built files, only the sources. If your documentation is generated from other files, don't check it in, have other developers build it themselves. Only if the files are hard to build would I check them into Subversion.
I don't tend to put a lot of binaries into subversion except maybe versions of the final product. Typically, if I can generate something on the fly, I don't bother, unless it takes too long to generate them, then I just stick them in there.
That said, I'd rather throw a copy of the latest docs (regardless of whether I can diff them or not easily) into svn if it makes my life easier. Always good to be able to put your hands on a copy (be it the latest or a previous version) of something when the boss or customer says "do you have the xyz document from October?".
As for your particular needs, well.. only you know for sure, but disk space is cheap and if there is value in having them there, I would do it.
Just my two cents.
My personal rule is not to add stuff you can generate from other stuff. Good example is documentation files that can be generated out of code comments.
If you have a documentation system that can be merged and diffed in a clever way I think the "source" for the documents should be in the tree. I.E the .tex file, not the .pdf.
If you branch off a release that needs edits to the code and the documentation, that documentation change will be in SVN as well. When you make a release you build the binary from the code and the documentation from the documentation source.
If you backport stuff from the branch, you can backport its corresponding documentation as well.
I put data that I create and potentially change into SVN. For example, I put source code, solution and make files, and documentation in SVN. I try to avoid adding generated files, such as PDFs generated from other formats, binaries, and third-party libraries. Content that I don't generate and change, such as manuals from other vendors, end up in a shared folder. That's all pretty consistent with what other people are saying.
However, I do add generated files and binaries when I'm (1) making a release and need to preserve the exact released files or (2) the files are difficult to build and I don't want other developers to deal with the build process. I sometimes add third-party libraries for convenience so that new developers don't have to find, download, and install them -- this is very helpful for me since many of my development machines don't have connections to the Internet.