SVN Diffs in FrameMaker

[Joseph Lorenzini]

Hi all,

Based on the responses that I have gotten, I realized I was not being very
clear about what I asking for. All version control systems have the same
problem: how can someone view and edit the same data but prevent the users
from overwriting each others changes. This is especially problematic when
two or more users edits the same file at the same time. Depending who
commits to the repository first, the other person's changes could be lost or
overwritten.

As far I know there are two models for handling this in tortoise svn:
Lock-Modify-Unlock and Copy-Modify-Merge. The Lock model is basically like a
network share, where the user checks out a file (locks it), which prevents
anyone else from editing that file until the user who checked out saves and
closes the file (or in this case commits the changes into the repository).
The Copy model means each user has a local copy of the same file, each
person makes their changes, and then commit those changes to the repository.
The SVN client would then be responsible for automatically merging the two
different versions into one final version and committing that version
(including changes from all users) into the repository.

I want to use the Copy-Modify-Merge model in framemaker but I can't  because
there's no utility that will automatically track the deltas in different
local copies and then merge the changes automatically. If I had this, I'd
have a system that

   - attempts to automatically merge received changes with local changes
   during svn update or svn merge
   - Show the differences between two versions of the same FrameMaker file
   as part of svn diff
   - Show line-by-line attribution for svn blame
   - multiple users can edit the same file at the same time, and when the
   users commit their changes subversion will merge them into a single file
   automatically.

Within that context, my system admin told me that this merging functionality
can be done by a third party tool which the SVN client could link into.
That's what I am looking for.

Steve Johnson suggested I commit MIFs instead. This in theory could work but
I don't think its scalable and would have significant negative impact on my
productivity. I have a very large documentation set. In 2 or 3 day time span
i will have changed many, many different FrameMaker files. For this MIF
commit strategy to work, I'd have to manually save the files to MIF each
time I make a commit. I dont' think I'd want to go down that route. Plus, by
making this process manual, the potential human error is far greater. What
if a user fails to save as mif and instead commits a frame file etc?

Sincerely,
Joseph Lorenzini

PS I don't know about anyone else but I find the built framemaker diffing
capability to be useless with large scale changes. The way it organizes and
tracks changes produces so much noise its hard to identify anything useful.
This would be a tangent but I'd be interested to hear if anyone's managed to
make the diffing functionality work on a large scale that is usable.