SVN Diffs in FrameMaker

[Joseph Lorenzini]

Hi Steven,

I find your response both confusing and incredibly peculiar.

I actually never said nor implied that multiple writers work on the same
files and don't talk to each other. I have no idea where you got that idea.
In fact, we communicate all the time  and its a time consuming process.
Right now to ensure that all the changes are merged together, I have to go
through and set up a methodical, step-by-step process with the other
writers. Furthermore because I am the only full time technical writer, I
have to frequently work with short term contractors that have little
knowledge of my documentation processes. Even with communication, the
chances for a mistake to be made just comes with the territory of a newbie.


*The whole point of my post was to find an automated process for
collaborating on FrameMaker documentation that significantly reduces the
chance of humor error -- not switch from one manual process to another*. I
want to optimize my workflow and manually saving and committing MIFs did not
sound like that would fit the bill.  In the first email I sent out, I
specifically asked if there was custom solution (eg some script) that would
automate the SVN merge process, which I could purchase. You never mentioned
in anything about scripting in your one line response, nor pointed to a
third party tool that would so. Therefore, I assumed you were describing a
manual process, otherwise why would you mention it?

In any case, I now infer from your latest response that you believe that if
someone does not have the ability to create their own script or code to
accomplish task, then they should not bother with solving rpoblems and
instead just stick to manual, time consuming procedure. I don't know why you
are opposed to the idea of purchasing tools from a third party to accomplish
a task but that's what I want. So I guess we'll just have to agree to
disagree.

For example, if someone has a script that would automatically convert my
FrameMaker files into MIFs, merge changes from other writers, and then
commit them to the repository, then that could be promising. Though, I'd
also, want the ability to check out the mif files and use the script to
convert them into Framemaker files (I manage over 30 books and 2,000 pages
of documentation mostly by myself).

I am also not sure how SVN blame and diffing would work with MIF files. I
tried it before with tortoise svn and while it did diff the mif files, it
failed to display human readable text.

Sincerely,
Joseph Lorenzini




On Wed, Nov 3, 2010 at 1:06 PM, Steve Johnson <chinaski69 at gmail.com> wrote:

> 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
>