Managing versions of documents - problems and concerns?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Svi Ben Elya needs <<...information on how you keep track of what changes
were made to documents, when and why.>>

We use revision tracking in Word 97, combined with both the versioning
feature and a group directory in which to store checkpoint backups. Here's
how that works:

The document template for our reports automatically uses Word's versioning
feature (under the File menu, select Versions, then select the
"automatically save a version on close" checkbox). During editing, we use
revision tracking. In theory, this retains a copy of all previous versions
(defined based on the state of the document at the time the file was closed)
in a single file. Via the same dialog box, you can select and return to any
version.

In practice, this works reasonably well, though there have been a few
suspicious incidents and I've heard others claim that this feature is too
flaky to trust. Because I'm concerned that Word can't always be trusted, I
always save a checkpoint copy before I begin my edits to provide a backup of
the state of the file before I began editing. I then open the Versions
dialog, delete all the old versions (to head off any file corruption), then
save the file and start editing.

<<What drawbacks are there to the method used?>>

Apart from any potential flakiness, the versioning feature isn't
particularly intuitive, particularly for authors who don't use it often. As
a result, most authors save their own backup copies. We do have centralized
server directories for this, but in my experience, not everyone uses them.
So we end up with outdated copies of the file stored all over the place.
None of these are "live", since there's only a single authorized copy
everyone works on, but you can imagine the storage problems.

<<What you would like to keep track of if you could find a practical way to
do it?>>

This isn't rocket science. Work on only a single "live" copy of the file
(preventing confusion over which version is the most current) and do
incremental backups each time you close the file. This gives you a day by
day snapshot of the state of the file.

<<Your feedback will be used as part of an overview of what issues are
involved in managing changes made to documents.>>

In my experience, we rarely return to older copies. But in organizations
where you have to assign blame for errors (so you'll know who to execute,
throw to the sharks, or retrain to do things right), there's some value to
at least having the option of returning to the older copies. But I'm not
convinced version control software is necessary for this.

<<Issue 1: ... How can Technical Support quickly identify whether
corrections were already included in the document or were
added later?>>

Using release numbers. When we make any significant changes, we change the
release date.

<<Issue 2: When more than one person works on a document, how does each
writer know what changes have already been made?>>

We avoid creating multiple "live" copies of a document. There's only one
"official" copy of the document, no matter how many unofficial copies are
spawned. It's the official copy everyone works on; other copies never get
passed on for review or rework. Because we work sequentially, it's never a
case of a second person working on the file before the first person is
finished.

<<Issue 3: Who made and who authorized a specific change?>>

In using revision tracking, the editor's identity is attached to all
changes.

<<Issue 4: When single-sourcing is used>>

Not applicable here.

<<Issue 5: ... How can I rollback to an old version of a document when
customers have problems with the newer documentation or the product is
rolled back? How do I identify what changes made to the document are
relevant to the older version of the product.>>

In the first case, it's simply a matter of returning to the previous
numbered or dated releases of the document. In the latter case, you should
ideally have some form of change history document. In my case, I create a
separate Word file containing changes to the documentation (e.g., "Changes
made in version 4.1"). This is what the SMEs review, and once approved, I
incorporate the changes in the actual documentation.

<<Issue 6: Version Management software commonly used by R&D does not always
identify changes made to documents.>>

Don't use it, so can't comment. But if you're using Word, it has a primitive
"compare documents" feature that will let you compare any two documents to
see how they differ.

<<Issue 7: When using a check-out/check-in system and different people work
on different chapters (FM files), how do you check for changes to an entire
book without checking-out all files, thus preventing writers form working on
the files.>>

We don't have that problem, but I imagine that my suggestion about "change
history logs" would work just fine.

--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada 

"Work is of two kinds: first, altering the position of matter at or near the
earth's surface relative to other matter; second, telling other people to do
so. The first is unpleasant and ill-paid; the second is pleasant and highly
paid."--Bertrand Russell

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

ANNOUNCING ROBOHELP STUDIO

RoboHelp Studio maximizes your Help authoring power by combining 
RoboHelp Office and RoboDemo, so you can easily create professional 
Help systems that feature interactive tutorials and demos.

Find out more about RoboHelp Studio at http://www.ehelp.com/techwr-l2

---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.