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.
>I've found this to be an effective way to control documents/files without
>spending $$$ on extra software (which also adds overhead to your
>system--something I definitely don't want) and losing control of the files.
I agree emphatically. Unlike software, documents do not conform well
to the paradigm of source management. Managing documents in source
control systems typically consumes disk space, money, and time
unnecessarily.
I once worked in a place that had us save FrameMaker documents
as MIF files, then check them in. The MIF file is an ASCII
representation of the doc, so the source control system was
able to compare versions and generate deltas. People familiar
with MIF file sizes are no doubt chuckling by now. Checking in
took *forever*, and the exercise was pointless: we never had to
re-release older versions of the doc. Eventually we were allowed
to check in doc binaries once per documented release, but it
took a lot of argument and a couple of releases.
Documents are binaries, source files are ASCII, and never the
twain shall meet. :-) (OK, icon bitmaps are binaries, but they
aren't versioned on a per-pixel basis.)
>Here's my suggestion: Create a solid
>document hierarchy on paper and then duplicate the structure in your file
>management system, whether it be File Manager, Windows Explorer, DOS, UNIX,
>etc. Place all files related to a single document in the same subdirectory.
>If you have any files common to more than one document, place them in a
>separate directory called "common."
Sound advice, but I would add: archive each version as it is released.
Also, if you share documents in the corporation (via the Web, for example),
keep a duplicate read-only document hierarchy for public access.
You can just copy the file hierarchy to update the public versions,
if you've planned well.
John
--
John Gough gough -at- austin -dot- asc -dot- slb -dot- com
Technical Consultant johngough -at- aol -dot- com
Schlumberger -- Austin Product Center C1.147 -- (512) 331-3656
