Strategies to Track, Maintain multiple variations/ flavors of Sales/ Marketing Word Documents with cross pollination?

Question

Strategies to Track, Maintain multiple variations/ flavors of Sales/ Marketing Word Documents with cross pollination?

• I've been reading interesting examples of people using Tortoise, Plastic SCM, Magnet SVN, Mercurial etc for maintaining word documents as well (with/ without various plugins etc.)
• I've read some basic info on SVN, Git, Hg etc.
• I have a technical background but I'd like to ask this from the Point of View of a Writer/ User. Now the question is not so much technical, but more so 'capability' based.
• At the moment, it will be a single user handling these variations/ flavors (myself).

Direction:

• I will be starting from a Master Word Document (Product & Services Sales/ Marketing Proposals).

• The eventual goal may not be a single Master Word Document but various independent variations/ flavors that this existing Word Document would take & maintain.

• There will be "custom" variations which may remain separate forever (for marketing & presenting to different people)

• Some updates, elements & data from these flavors/ variations could sometimes be "shared" and "merged" with each other and certain parts could remain Separate & Distinct for good.

• There is no eventual goal to Converge into a Single Flavor/ Variation.

• These are being customized to appeal to varying customers and clients but would love to have some way to interpolate/ cross-pollinate the improvements over time.

QUESTION:

• Are these version control systems CAPABLE of managing/ handling such "long term" flavors/ variations with Cross-Pollination for these sales/ marketing documents?
• If yes, then please suggest some 'strategies' on executing these many flavors/ variations? I've read 'branch, trunk, tags, clone' in relation to Code. What would be good strategies/ execution ideas here?

Thanks in advance. Please do advise.

PS: Of course, Visual diff & Interpolating/ Merging parts of Word Documents would happen often.

Answer 1

For Word documents, you are probably better off looking at document management systems than SCM systems.

For example, in the Java world, alfresco, eXo, nuxeo etc. I wouldn't call it light, but you can run alfresco on a laptop.

Some DMS provide special support for content re-use.

If you weren't working in Word, you could use an XML component management system. See for example http://en.wikipedia.org/wiki/EasyDITA or http://www.componize.com/

In fact, you can use that sort of approach. You could shred your Word docx (ie unzip it, and then split out the re-usable chunks) into eXist or MarkLogic. These systems can dynamically re-assemble the document when someone wants to view them in Word. The re-usable chunks could be versioned separately. And you could have an interface for re-combining to create new documents. The pieces are there, but you'd need to do some (not inconsiderable) development yourself to create a complete system.

Some links to get you thinking (Google "component management" ECM OR document):

• http://www.cmprofessionals.org/index.cfm?fuseaction=Feature.showFeature&featureID=41
• www.single-source-forum.de/rueckblicke/2005/folien/ssf05_folien_kuppers.pdf
• http://www.component-management.com/

Another approach entirely would be to look at document assembly systems. Some of these support components (content re-use). Document assembly systems also enable you to have a single 'smart' template, which contains all the variations, instead of multiple documents.

If you Google 'document assembly', you'll see systems which are available at all price points (from free, to v expensive). See further http://en.wikipedia.org/wiki/Document_automation and http://www.americanbar.org/publications/law_practice_today_home/law_practice_today_archive/september12/magic-in-minutes.html

Answer 2

Well, from my POV, your task can be easy powered by any existing SCM (most headache will go from ugly MS-side, not VCS).

AFAICS, your history will be strictly linear, thus - you can don't worry about "better|worse merging" (in any case merging Word-files is terrible nightmare).

I think, you imagine you workflow slightly incorrect (as I see your task): at some stage you'll have a set of: * Master Documents * (different) files , different combination of which are included in different Masters as Subdocuments

All Masters and Subs are versioned and, therefore, changes are tracked. Reordering of parts in Master and|or adding|deleting|editing Subs files change final business-documents