I note that there is no way to edit a topic and save it, BUT not publish it for the world to see. This would be useful when the statement of the topic is relatively complex, or if it was desired to gather some edits to a document for those who have edit rights, but not changing the base document.

-- RaymondLutz - 02 Dec 2003

I would like to be able to branch my topic temporarily so that my change is not the one automatically displayed (i don't want to make it totally private though). I'm thinking of using this for storing, displaying and updating our ISO9001 procedures, where the HEAD revision (the one displayed) will always be the authorised version, and any time that someone edits the topic they go to the branched version (so we don't have to worry about merges). I don't remember if this has come up before, so i won't create the FeatureRequest topic yet

-- SvenDowideit - 02 Dec 2003

Let's summarize the uses of this sort of feature so we can flesh out the requirements a bit more. The idea is to have perhaps a new checkbox at the bottom of the topic that could be checked to save the current version as a revision, but still use a prior revision as the published version, or save the document and not publish it at all. Before, we try to envision how this could be done, we can see that it would be useful in the following situations:

• I have lost edits from time to time when working in an edit window. It would be nice to allow saving the document on the server so that it is not lost due to user or browser goofs (like clicking refresh when working on the edit window. As Homer would say: DOUGH!)
  • SavemultiCgiScript, and therefore CheckpointSave, are now part of CairoRelease
• Allowing users who have edit rights to begin to amend the document without changing the published version.
• Preview would probably show the amended version of the file, so you could see what changes you are making to it in a rendered form. Not important for WYSIWYG (HtmlAreaEditor) editing as you would see the changes.

I think the way to implement might be to indicate which version of the file would be used for rendering and placement in the web directory. Normally, this is a "configuration control" sort of topic that is part of the Version Control System. I am not an expert on RCS, the revision control system used by TWiki, but from my recollection, it doesn't have this functionality. We would need to provide configuration management ourself, most likely by adding it to the Topic Object. I have added such a proposed object property of the TopicObjectModel that will indicate which version of the file is displayed. You need a place to store this that is NOT in the published file as it would obviously be impossible to indicate that an alternate version would be used.

-- RaymondLutz - 03 Dec 2003

rcs does allow you to mark which revision is the default one - this would be the published version. then we would need to do a different checkout for the editing (in a different location from the view checkout (this would be a change from our current system..)) This will be interesting to implement in such a way that it supports moving to CvsPserver support for DistributedTWikis.

-- SvenDowideit - 03 Dec 2003

If by convention, the version used for any edits was the end of the revision tree, and viewing was the published version, i.e. the default version, that would handle your ISO document questions, but would not allow editing and saving a topic without publishing at least one version. A quick work-around, would be to insert a blank revision 1.1 and mark it as published, i.e. the default version, and the initial (unfinished) version as revision 1.2. By using the functionality in the RCS system, this would eliminate the requirement for TopicObjectModel property, but it may still be the right way to implement it so that the specifics of the RCS system would be suppressed. We would need to insure that the version that sits in the Web directory that is used for searches would be the published revision, and not the latest revision. I think this relates to your comment about hte "different location".

I see no additional problems not already experienced with the DistributedTWikis concept, as currently envisioned. My initial reaction to the way the DistributedTWikis was addressed is that it is a hack and is not something that you normally have to respect. In essence, the way it is handled now is a crude method of revision branching, which is subject to merge conflicts that require heiristics or manual editing in some cases, especially if the same text is modified by two parties. Viewing causes no conflicts and most of the TWiki would be viewed, not edited. If you edit, it would be best to have a Web-Services interface with the "central" TWiki site. But that is a comment for another topic, and so I won't rant and rave here. My point is that it doesn't seem like it would break the current DistributedTWikis implementation at first glance.

-- RaymondLutz - 04 Dec 2003

errr, when i refer to DistributedTWikis i mean the concept, not the current implementation. I will (assuming current company plans continue, and i have time and money for it) be needing proper, multi-site, simultainious edit, auto-merging DistributedTWikis that will be extremely important to the day-to-day running of the business.

cool huh

-- SvenDowideit - 10 Dec 2003

I don't think there is much to consider then as you are faced with the same situation except for one more piece of information, i.e. which revision is selected as viewed. The dirty deed of combining separate twikis that both have edits in the same area will continue to be a problem unless there is a common checkout-for-changes web service, which is what I would advocate if possible.

-- RaymondLutz - 10 Dec 2003

i disagree. like with bitkeeper, i expect to be able to do irregular syncs between twiki's (by considering each as its own branch?). I want this funtionality to work of offline, fully peer twiki's too. my rough thought is that there is a master twiki (thank god i work in the main IT office) and that the other twiki's sync those changes into the main branch, and they make their changes into their own branch, then the merging can happen to the main branch (i don't have a probem with conflicts as they can be refactored out by any user). the final touch comes when you then move the HEAD tag to change what topic is the viewed one..

and at the same time, i expect i will want to write the CvsBackend (and cvsup?) to facilitate the backend syncing.

-- SvenDowideit - 10 Dec 2003

I don't think it is as easy as you make it sound. If everything was just freeform text, then i don't have a probem with conflicts as they can be refactored out by any user may work. However, if you are talking about structured content, it is much more problematic. I have been through 100's of merges and they always are a pain when the same file and perhaps the same text is changed by differing individuals. It is interesting, but I don't want to work on it.

-- RaymondLutz - 11 Dec 2003

yes - i am trivialising it a lot - i would like to do the work, but i suspect someone would need to pay me to motivate me to do the last 10%-20% - cos that spec&design would be time-consuming. I think you have helped me realise why a reason why i am not comfortable with the METADATA system. I always wondered whether the hidden content would bite us - and in a multi-way merge we could end up with an uneditable mess. When i did the other implementation (which i don't own) i just had text based name value pairs that would get rendered as forms, with 2 types of edit views - a raw text one, and a form based one. this would then give us a failsafe way of fixing merges. I also agree that this method does not scale well... but so long as the persons who did the change has to figure out a merge (even if some get defered), i think it would be workable.

-- SvenDowideit - 11 Dec 2003

OK, now you've got me thinking about this, and like it or not, my mind continues to grind away, coming up with ideas. Here we go.

In the past, I have used a very advanced version control system, at the time called DSEE, for Domain Software Engineering Environment, which ran on Apollo systems running an operating systems called Aegis. Of course, all this is history, but the DSEE system did have quite nice support for not only revision control, but also configuration management, branching, and merging. All this is related to both the SaveUnpublished question as well as the issue of DistributedTWikis. One important difference between DSEE and other systems I have used such as CVS, PVCS, etc. is that it was very good at managing MultipleLinesOfDescent. In the current TWiki implementation, there is support for a single line of descent, with no branches, and with the current (editable) version always at the tip. In general, you have:

• MultipleLinesOfDescent, i.e. a branching tree, and
• the ability to select any version as the view default (This is the subject of this topic: SaveUnpublished)
• and another as the edit default. We assumed that the tip would be the edit default to this point.
• Of course, you would also be able to edit from previous versions on the tree, thereby creating a branch.
  • If you had two versions for the same file from DistributedTWikis, they would create a branch from the common version.
  • You would want the ability to merge the branches to result in a single line of descent.
• It is more difficult to express a branching tree instead of a linear list.
  • TWiki now shows a linear list with all versions based on the same branch, i.e. 1.XX, were XX is the version.
  • The support for branches generally requires somewhat of a graphical display, with N.XX where N is the branch and XX is the version of that branch. Graphics is helpful as it denotes which version the branches have as a common parent, and therefore, which version the differences will be based on when a merge is started.

OK, I got that off my chest.

-- RaymondLutz - 12 Dec 2003

It occurred to me again last night that not only do I want to be able to save a single page unpublished, but a whole set of them. This allows me to ensure that the web, as seen by others, is rational, coherent and complete yet allow me to work on it slowly.

NB. I do mean a set - as a subset of a single web. (Hmm. maybe even a set of cross-web pages to be published as the same time).

-- MartinCleaver - 12 Dec 2003

That concept fits well with the traditional concept of configuration management, and the creation of versions. However, as with TWiki, each topic is conceptually on its own in terms of its revisions, branches and lines of descent. If I can paint a picture of two paradigms:

• Folder Revisioning: If you are working with a small group and a small system, this can work well. Basically, you have a directory of files that are revised for each version of the program. The most recent version of the files are kept in the "folder" and the entire folder is revised. Some files may be unchanged from one version to the next.
• File Revisioning: you conceptually keep a separate "folder" for each file in the system, with the many versions of a single file in that directory, choosing the file you wish for a given "release". This method uses less space as redundant copies of unchanged files are not kept in two versions. With RCS and other infrastructure, the directory concept is suppressed but you still can obtain any version in the tree for a given file.

TWiki is based on the second concept. This is a very wise choice, but it does not have the administrative tools to do ConfigurationManagement which is the ability to select which versions of the files are used for a given release. Usually, the way this is handled is that version Labels are used to label versions according to a larger construct. For example, the RCS system uses revision names like 1.X where X is the revision of the file. It may be possible to label revisions so that it would be possible to say "Make all Version "Paris 1.0" default, and all files that have a revision marked as "Paris 1.0" would be made current. Of course, it would be not too hard to say that all files in a given web (or other OrganizingPrinciples ) would go to the tip of the main line of descent.

-- RaymondLutz - 16 Dec 2003

---

moved here from an autosave vision --mhw generally the problem i have is not wanting to commit the changes until they are complete. to solve this problem, it might be useful to choose when to save a temporary copy, rather than having the meta refresh interrupt. the edit page could include two buttons perhaps, one labelled "preview" that functions as it does presently, and one labelled "save temporary" that will write a temp file (i would prefer web, topic, and username rather than ip, for after a crash, the ip address will often change), then return to the edit window. this has the added effect that one can make some changes, and postpone committing it until the changes are complete, even after closing the browser and/or using a different computer. if the user edits the page again after the temporary file has been saved, it will bring up the temporary file instead (with a warning probably).

concerning file locking/concurrent editing: when the edit link is clicked, twiki should check for a temporary file. if the user that clicked edit is different than the user that saved the temporary file, it should display a warning discouraging the user from editing the file while it has been modified but not committed by another user.

just a suggestion... :^)

-- SteveMokris - 3 Aug 2000

Actually when I get around to finish the new locking system, after finishing PackageTWikiStore one of the side effects will be an easy way to: "Edit current or Edit yesterdays version you left uncommited."

The CVS code I wrote actually almost does this as well.

-- NicholasLee - 03 Aug 2000

---