[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

Re: Source Control



On Wed, 6 Feb 2002 17:59:08 -0800 , Rosemary Rooks 
<rosemary.rooks@peregrine.com> wrote:

>I have been trying to get source control for doc. 
>"Everyone" tells me that it can't be done because 
>.fm files have to be stored whole, rather than just
>the changes, and it would take too much space. Does 
>anyone know what we can use to do efficient source 
>control on our doc? 

We keep our Users Guide in CVS, the same version control
we use for Mif2Go source.  Same source tree, in fact.

It's true that saving .fm files (as binary, essential)
would give you bloat and prevent the usual CVS comparison.
However, it *would* give you a good backup system, and you
*can* use FrameMaker's own comparison tools to see the
differences between different retrieved versions.  It's
certainly the fastest and simplest way to establish
some source control.

We went the other way, and saved as MIF, putting the
results into CVS as text like the rest of the source.
(We also put in the referenced graphics as binary.)
While at first this seemed a good idea, we've run into
some practical problems.  

For example, we have a large, and often changed,
Frame-generated index.  We began getting crashes on
the CVS server (a UNIX system) from out-of-memory
conditions during commits of the IX, leaving behind
*big* temp files that had to be removed by hand on
the server, as we discovered by running out of disk
allotment.  :-(   We had to exclude the IX from CVS.
No problem, we can always generate it, but still,
you might run into such a problem with any large
file where changes are frequent.  Our IX was only
358K in MIF, but the CVS file of it was a few megs...
it's gone now, so I can't tell you exactly.

There are also some practical difficulties in making
MIF that really works when you get it out again.
You need to create the MIF *locally*, in the same
dir as the .fm files, and rename the MIF with .fm
extensions so that the book file will accept the
reloaded copies.  You also need to make a MIF of
the .book file itself *locally*, then rename it.
Since we are the authors of Mif2Go, we simply built
all this into M2G as a new format, "MIF" output <g>,
which handles all the little gotchas for us (and for
our customers).  If you don't have Mif2Go, you will
have some tedious and error-prone tasks ahead.

Finally, the CVS files containing the MIF and the
diffs get very large.  Our entire book minus IX,
in MIF, is 15MB.  But the current CVS archive of
the MIFs, with the diffs in them, is 47MB, and
will never shrink, only grow.  This is not an
issue with a local server, but if you are using
CVS for collaboration over the Net it may be.

As always, YMMV depending on book sizes, update
frequency, and number of collaborators.  HTH!

-- Jeremy H. Griffith, at Omni Systems Inc.
   (jeremy@omsys.com)     http://www.omsys.com/
** To subscribe to Free Framers, email the message **
** body "subscribe framers" to majordomo@omsys.com **

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **