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:Randall Raemon <rlr -at- HAL -dot- COM> Date:Mon, 19 Dec 1994 12:02:25 -0600
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.
> My first thought is that it isn't necessary. Instead, I can just
> have one directory of "last version" docs (with a tape backup and
> hard copies), and then one directory with working docs.
If that has worked so far, and nobody has complained, then keep doing
it. Details follow.
> Granted, I need to work out a system to track the docs., however
> recording numerous small changes (for example, a single re-worded
> sentence) seems like overkill.
You're now getting into the fun subject of configuration management.
The project as a whole should have some CM policy already spelled
out. Trying to do things piecemeal will simply make things much
worse if there is ever a cause to try and go back to recover an old
version.
The CM policy should say very clearly what the capture points are
with regard to project milestones, and problem reports. The point of
any CM system is to be able to recreate exactly a prior version at
some point in time. Those points in time must be clearly spelled out
in advance. Otherwise, capturing everything in sight is a great
way to stay busy, but not really accomplish anything, except having
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...)
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
