Re: [austechwriter] Merging of Framemaker files on Clearcase

["Jeremy H. Griffith" <jeremy@xxxxxxxxx>]

On Fri, 5 Apr 2002 15:04:31 +1000, hedley_finger@myob.com.au 
wrote:

>Subash:
>
>> Our versioning environment is Rational Clearcase and we use 
>> branching system to maintain various versions of the process
>> documents. I would like to know whether Clearcase can merge 
>> Frame files as it merges Word documents. If yes, how fool-proof
>> is the process and what are the drawbacks (if any)?
>
>You can safe your files as MIF, an ASCII text format like RTF and save 
>them to your repository.  Then you can merge the branches back together.
>This works with Visual SourceSafe but I would suggest requesting an
>evaluation copy of FrameMaker from Adobe to test whether branched 
>versions can be merged under ClearCase.  

We did this for some time using CVS as the repository manager, for
our User's Guide.  We saved as MIF, and stored the MIF and graphics
in the CVS archive.  We were easily able to retrieve docs produced
at one site from other sites, and had the added advantage of off-site
backup.  And CVS itself is both free and widely used.

However, we never tried to do any merging with the MIF, and I suspect
it could be problematic.  For example, suppose two authors work on
different parts of the same doc, adding paragraphs, then commit the
changes.  Because of the way Frame creates identifiers, the same IDs
will be used for the new (different) paragraphs in both docs.  CVS
will not notice this; it will just merge into a new MIF, which will
now contain illegal duplication of the <Unique> IDs.  Not so good.

If the two authors make conflicting changes to the same area of the
file, CVS will notify the second to commit, and offer the MIF to
edit (with non-MIF CVS lines interspersed) to resolve the conflict.  
The author had better know how to edit MIF directly!  This is not 
impossible, we do it all the time, but it's not trivial and is not 
a common skill.

We ran into a severe problem with generated files, where after a
few revs the archive file (with all the change info for each rev)
ballooned into a multi-megabyte monster which brought the CVS
server to its knees.  Most source-control systems are designed for,
well, C/C++ *source*, and those files are usually small, often only 
a few K, rarely over 50K, and almost never over 100K.  MIF files,
OTOH, start at 100K, and rapidly move into MBs, even if you are
religious about referencing graphics rather than embedding (which
is absolutely essential for any source-control system usage).  We
wound up having to remove the IX and TOC from the system entirely.

We suspended use of CVS for this about a month ago because the
archive was just getting too big, about 30 times the size of the
book and growing.  Instead, we now make up a .zip of the .fm files
for each rev, and archive *that* as a binary file, opaque to CVS.  
If we ever do need to merge, we can unzip whichever rev we want into 
its own directory, then use Frame's own file-compare tools to do the 
merging.  Much safer and easier than using any tool that does not 
itself understand MIF...

>There is a FrameMaker plug-in called
>mifSave which can save each component file of a book to MIF, so your
>writers can work with the binary *.fm format while developing, then save to
>ASCII *.mif files for checking in.

We actually wound up adding MIF as an export format to Mif2Go
specifically to support our own CVS use.  There are a few little
tricks needed to generate MIF that is really usable with such a
system.  For one thing, we needed to MIF the book file itself,
as well as the chapter files, in such a way that the references
were not "fixed up" by Frame (which would make the files very
hard to reload later).  This also meant naming the MIF files with
the original Frame extensions, something Frame just won't allow
you to do manually.  Finally, you'll need to put the whole set
into another directory apart from the rest of the Frame files.
Our MIF export function handles all that pretty automatically;
after a real simple setup, it's a button-push operation.

If anyone wants to experiment, this feature is present in our
sample version of Mif2Go, available at:
  http://www.omsys.com/dcl/download/samp33u23.zip
(the "23" part gets incremented every few weeks).  For this
particular output, the sample version does *exactly* the same
thing as the licensed version, and we hereby authorize anyone
who wants to use it for that purpose to do so (commercially) 
in perpetuity without fee.  Enjoy!

-- Jeremy H. Griffith, at Omni Systems Inc.
  (jeremy@omsys.com)  http://www.omsys.com/

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