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: Servers vs. local From:Matt Hicks <matt -at- UNIDATA -dot- UCAR -dot- EDU> Date:Fri, 4 Nov 1994 16:51:30 -0700
On Fri, 4 Nov 1994, Arlen P. Walker wrote:
> The recent discussion on FrameMaker backups brought a thought to mind. One of
> the posters took it as an article of faith that you never work on files on the
> server. You first copy them down locally and work on them, then copy them back
> up. There's a group here who see the copying as wasted effort, and simply work
> off the server. (There's the complete previous edition, and then the "work in
> progress".) That way they never have a situation where the server does not
> contain the most recent copy.
> I'm assuming all version control systems force copying down to local discs. So
> for those of you working in networked environments and not using version
control
> systems:
> a) Do you work on the server?
> b) What do you see as the *best point* in favor of the way you're doing it?
We use the UNIX version of FrameMaker and we recently ran into some
serious problems when we tried to put our Frame documents under a version
control system.
The problem arises because the version control system allows more than one
person at a time to make changes to a document. It then attempts to merge
changes made in multiple copies of the document. This works fine when people
are writing code or other plain ascii text, but when it tries to merge two
Frame files, it creates garbage because Frame files are binary. This is a
particular problem when two people have made changes to their own copies of
the same file; one of them can commit their changes to the central archive,
but the other has no way of incorporating those changes into their copy, nor
adding their changes to the copy in the archive. We had to restore from
backups twice when this situation occurred and the archived files were
munged. This also circumvents the lock files that Frame creates that prevent
anyone from making changes to a document when someone else is working on it,
thus negating one of Frame's many useful features.
Working "on the server" is not really an issue since I do my Frame work on an
X-term, which is always running on a local host--i.e., I have no choice but
to work on a server. But to respond to the spirit of the question, we have
determined that from now on, we will make our changes directly to the files
in the central archive for each document. This will ensure that the documents
in the archive are always current. FrameMaker has its own built-in mechanism
to prevent people from making conflicting changes to a file, and this
mechanism has served us well in the past.
-----------------------------------------------------------------
Matt Hicks, Tech. Writer, Unidata * I may not agree with what you
Boulder, CO, (303)497-8676, ******* say, but I'll defend to the
matt -at- unidata -dot- ucar -dot- edu ************* death my right to mock you.
