Post History

Source: https://writers.stackexchange.com/a/13019
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/

I have used source control in documentation for several reasons besides multiple writers working on the same file. Some other uses are:

- Tracking and communicating changes
- Deploying documentation to a web site
- Integrating documentation with software builds. For example, I worked in a doc/software system that facilitated linking javadoc to other documentation.
- Documentation review. Depending on the format of your documentation, you can use the same review tools that software engineers use for reviewing their code. For example, HTML documentation is relatively easy to review this way.

I also think that you should strive to divide up documentation tasks so that writers work on their own set of files whenever possible. I can think of a huge number of reasons that this approach is preferable.

Having said all this, here are my specific answers to the OP's question:

You can generate PDF from HTML or XML, given the right tools. PDF is so popular that many tools support it out of the box. Because PDF is Adobe, the best PDF generation support is from FrameMaker, alas.

If you want source control without a cloud server, you should look at Git, which is an open-source distributed system. Technically speaking, Git doesn't have a "central" repository. Instead, everybody that's interested in a set of software , documentation, and so forth gets their own copy, which is called a repository. All repositories are created equal, and each one can be branched and merged at will. Most of Git's software handles merging and conflict resolution.

I can't answer for the overhead of the tools for generating PDF, but the overhead for Git depends on the number of files and the type of each file in each repository. Internally, Git tracks changes to text files rather than the entire file itself, but Git can't do this for binary files (such as .fm or .doc).

Original score: 0