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.
