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.
Jennifer Tibbs wrote
> The problem is, our naming conventions were confusing
> students. A file name looked like this:
> TibbsJS_rev_00.doc for the original version. Every
> time someone edited the document, the number should be
> incremented. We wanted to preserve each version of the
> document for practice with editing and using FTP (to
> download and upload resumes to the appropriate places
> for the authors to look at). However, because of
> inexperience and bugs within the system, very few
> participants understood the file naming conventions.
> We had a terrible time trying to teach everyone and
> manage the files at the same time.
>
> I am looking for, from all of you, suggestions for how
> to redo the file naming system to simplify it for this
> year's students.
IMHO the file's version number or date ideally shouldn't be part of the
filename.
The file date is a property of the file and is always viewable in your file
manager, so the date shouldn't be part of the filename, else you could get
out of sync, like this:
09/23/2003 resume_081703.doc
If you have a version control system, let it hold the version numbers as
metadata. Don't increment the filename, else you could have a file like
"resume_rev_003" which your version control system reports as v6, or some
other version number.
But if you don't have a version control system and you are just using your
file system, then just increment the versions with a simple incremented
number. Don't try to pack the filename with other kinds of data.
Here's a system I sometimes use for versioning: Increment the old versions,
not the current document. For example:
1. Create resume.doc.
2. Before updating resume.doc, save it in the "old_resumes" folder as
resume001.doc
3. Then update resume.doc
4. Before updating resume.doc, save it in the "old_resumes" folder as
resume002.doc
5. ... and so forth.
This way, the current version is always named "resume.doc" and the
highest-numbered version is the prior version. (There is still the
possibility for human error; i.e. you could forget to save a version before
you update.)
Interestingly, VMS handles versioning as part of the native OS. Every time
you update a file, VMS saves the initial version with an incremented
filename. I'm not sure if any other OSs do this, but their may be add-on
utilities.
> We wanted to preserve each version of the
> document for practice with editing and using FTP (to
> download and upload resumes to the appropriate places
> for the authors to look at)
One problem with incrementing the current version: If you are uploading
"resume_rev_00.doc" to your website, what happens when you upload
"resume_rev_01.doc"?? Suddenly your website has two copies of your resume,
but nobody can find the current version because all your links point to the
old resume, which is still there.
Another problem with incrementing the current version: How do you know which
version is the current version? You don't, unless you have access to all the
versions and you can select the most recent.
I see a lot of workplaces resolve this problem by sending review copies
around as email attachments; the recipients then sort the emails by date and
pick the most recent. This works, but as a version control system it's
pretty ugly.
NEED TO PUBLISH YOUR FRAMEMAKER CONTENT ONLINE?
?Mustang? (code name) is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to Web, intranets, and online Help.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! See a live demo that
will take your breath away: http://www.ehelp.com/techwr-l3
---
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.
