TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Tracking document versions... From:"Susan W. Gallagher" <sgallagher -at- STARBASECORP -dot- COM> Date:Mon, 19 Dec 1994 16:49:50 -0800
Randal Raemon gives some interesting insight on version control:
> Coming at this from a software background rather than as a
> writer...
> In message <9412191357 -dot- AA26155 -at- hal -dot- com>
> Paul MacGyver Carman writes:
> > The software group with which I work tracks their software with a
> > product called Aide~De~Camp. This package stores only the changes in
> > code, rather than storing ALL of the code.
> Actually, there is at least one full version stored, then all the
> deltas from that version. The way the deltas are produced is how
> the various tracking products distinguish themselves.
> > It was mentioned by one of my project leaders that this product
> > could be used to store documentation changes as well.
> True. But be careful of the products you are using. Some
> combinations are actually counterproductive. Consider, for example,
> Framemaker and SCCS on some systems. Framemaker stores files in what
> SCCS considers to be a binary format, so SCCS recodes the files for
> storage. The recoding completely overwhelms the delta storage
> mechanism, and consumes disk space like crazy. However nroff files
> store just fine. Check your combinations before diving in.
This is, indeed, a problem with delta/reverse delta storage. For many
binary files, and for some machine-generated ascii files (like the
.rtf files that many help creation utilities generage), computing and
storing the differences can actually take up more room than the original
file does. We (StarBase) use an omega storage method for binaries --
just store the whole d**n file! It's faster, more efficient, and uses
less disk space over the long run. And, you don't have to keep every
version around forever. Usually, you configure the software so that
older versions "drop off" as new ones are stored. (We do use reverse-
delta for ascii files, but you can optionally specify omega for those
nasty .rtf's) ;-)
[snip some serious version control conversation here...]
> hell to pay when trying to recover something.
> (Okay, we need the version from last Friday that we had for the demo.
> Was it Wednesday's stuff that went in, or Friday's 8am or 10am stuff?
> That's for this chapter, but what about the stuff in the other files?
> Oh, also we want the result recreated by the end of the day today...)
Where have I heard that before??? Being able to revert to previous
versions... Being able to compare two versions... All serious reasons
for implementing version control in some form!
> If things like project management and configuration management draw
> blanks stares, don't worry about trying anything except for your own
> amusement.
> Good luck...
> --
> Randall Raemon
> rlr -at- hal -dot- com
> delta1 -at- netcom -dot- com
> 0005650778 -at- mcimail -dot- com
I'll echo that sentiment! Good Luck!
Sue Gallagher
StarBase Corp, Irvine,CA
sgallagher -at- starbasecorp -dot- com
