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
