possible solutions for version control of hierarchical documents

Question

Hello internet techno-persons,

I am writing a project for users to create documents from document elements (basically images and html fragments).

The top level documents will be under basic version control (where every save increments the version number, and all previous versions are kept in the db)

The document elements will also need to be under version control (if the user edits an html fragment or uploads a new image, the version of the element gets incremented)

My problem... when an element has its version incremented, i need to show the user which documents the element is referenced on, and for each referenced doc give them some options, its these options that I cant get my head around,

do i give them a choice of

• Update document to reflect new element version (increasing the document revision in the process)
• Keep document in original state, referencing original element (which is one below the current revision - not ideal in my head, but I want YOUR ideas)
• Flag document as needing attention, and stop user from using said document until they have resolved the conflict (delete element from doc)
• delete the reference from doc to element(incrementing doc version in process)

This is really a usability and user preference issue, not so much a programming one. I would love to hear from people that have used similar systems - especially gripes you had with them, things you wished they did, so forth...

I hope I have made my problem sufficiently clear, any further questions, just ask!!

Thanks in advance,

Alan.

Answer 1

I had the same sort of issues with assets in different projects. My projects required validation before publishing, so silent changes without validation were not acceptable.

I would not change a document without a check from the writer to validate "silent changes". I would let him consult a possible new version wih updated references, and leave him the choice to update the references, or keep the previous ones.

Like code sometimes, people prefer to keep the working version for quick publication than trying to update things to work with the new shiny version :)