- From: Christopher Seiwald <seiwald@perforce.com>
- Date: Wed, 28 Aug 1996 10:38:08 -0700
- To: w3c-dist-auth@w3.org
Jim asked me to put together a few scenarios for distributed authoring. Below are a few offerings, with a bit of emphasis on the problems I've seen managing our web site and a few pot shots from the SCM world. This certainly doesn't cover all the vagaries of the problems we need to address, but it is a stab at real world versioning of web content. The scenarios are: 1) Two people trying to change the same document. 2) Revising a set of documents and publishing them when complete. 3) Reverting the revised document set. On we go: 1) Two people trying to change the same document. A certain Web site is maintained by two people, both of whom make changes on an ad hoc basis. As is frequently the case, there are a few documents that are hot points of congestion, even between these two people. Both people have a fancy, version-aware Web authoring tool that interacts with their Web server. "Joe" downloads a document from the Web site, and decides that it needs work. He clicks on the "edit" button from his browser/authoring tool, and the tool reports two things: first, that the Web server has acknowledged his edit operation (giving him assurance that a subsequent PUT will not be a complete surprise to the server); second, that the document he will edit is identical to that which he viewed. This may not always be the case: sometimes the document viewed by users is not the true, editable source of the document. But in this case it is. Joe proceeds to revamp the document. "Jane" meanwhile is viewing the same document and realizes that in the document the word "fuchsia" has a typo. Jane also clicks the "edit" button, but the authoring tool has a lengthier report for her: in additing to what Joe was told, Jane is told that Joe is also working on the same document. Jane calls Joe and they reach an agreement: Jane will make her fix now (because the error is embarrassing) and Joe will make sure this alteration makes it into his revision. Jane makes her changes and clicks the "save" button. Her authoring tool prompts her for a brief description of her changes, and then the server informs Jane that her change has resulted in a new, named revision of the document, and that name is displayed. Joe forgets what he was doing, and weeks later (while working on something else) clicks the "what am I working on" button. In the long list of documents that Joe has started to change is the document we've been discussing, and Joe decides it is time to finish it off. He makes his final edits, and clicks the "save" button. Joe, however, gets a message indicating that what he edited is no longer the latest version of the document, and Joe clicks the "merge" button. The authoring tool has the latest and greatest merge mechanisms, and in the process of resolving Jane's work with his he realizes that Jane did more than just fix the misspelling she said she would. That doesn't matter, because the merge mechanism uses actual differences, not verbally stated intentions. Joe again clicks the "save" button, and this time he is prompted for a description and his new version of the document is saved. 2) Revising a set of documents and publishing them when complete. Jane and Joe's version-aware web server is fairly simple: normally, it serves up the latest revision of each document, but if instructed it will instead serve up the revisions of documents as listed in a named configuration. In this way, they can make their trivial changes and have them show up immediately, but if they plan to make a heavy-duty overhaul they can save the current set as a working configuration and tell the server to use those until the work is complete. (This can all be carried out without the explicit knowledge of Jane and Joe's authoring tool, because the Web server makes itself configurable via Web pages with forms on them.) Joe is about to make a set of minor changes, and to be on the safe side tells the server to save the current configuration as "stable", a name he uses for these occasions. He goes through the various documents, clicking "edit" on any that he thinks are in need of updating. Once again Joe forgets what he is doing, but a few days later the "what am I working on" button again comes in handy. He realizes that his work is about complete, and makes his final edits. Joe's changes really are a coherent set that should appear simultaneously, and he doesn't want to find out halfway through saving that Jane has made changes that need merging, so he clicks the "Save All" button. Fortunately, Jane has been busy viewing _other_ parts of the web and hasn't made any changes to their local Web pages, and so Joe is prompted for a description of the changes he has made. Since Joe is saving all the documents at once, a single description applies to all the changes. One by one the new documents are saved, and in the end Joe gets confirmation that all documents are in place. Joe browses the result and is satisfied that their customers are seeing what he has just finished. Joe goes on vacation. 3) Reverting the revised document set. Jane gets back to real work and realizes that every document that Joe edited has the same old spelling problem. In a panic she calls Joe but realizes that he is on vacation. Knowing that the errors would harm their image, she decides to undo what Joe has done until he returns and can correct his mistakes. Jane begins by browsing the revision history of each document, and notes that all the erroneous documents came about at the same time when Joe saved his changes just before vacation. Jane browses the configuration lists in the version-aware web server and sees that Joe had made a "stable" configuration before his latest work. Jane instructs the server to serve up only documents from the "stable" configuration. As this doesn't involve changing any of Joe's work, it is a quick fix to the pages on their public web server. Jane now browses the documents on their server and is satisfied that they are the precursors to Joe's latest change. When Joe returns, he fixes his spelling mistakes and then tells the server to resume using the latest documents. --- Christopher ---- Christopher Seiwald Perforce Software www.perforce.com seiwald@perforce.com f-f-f-fast SCM 1-510-865-8720
Received on Wednesday, 28 August 1996 13:39:21 UTC