SVN Diffs in FrameMaker

[Steve Johnson]

So don't do that? You're saying that multiple writers work on the same
files and don't talk to each other? Given that, you will never get
anything to work properly.

A group of 20 writers checked in and out MIFs successfully for two
years or more. It is not a negative impact to anything if you do it
right. All you need is a way to script from FM > MIF > FM. Plus, SVN
most likely stores the diffs only so you're saving a lot of space in
the repository by not checking in binary FM files.

If you can't script it then don't do it.

On Wed, Nov 3, 2010 at 12:20 PM, Joseph Lorenzini
<panopticon23 at gmail.com> wrote:
> 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.
>



-- 
============
Steve Johnson, dr_gonzo at pobox.com