|Date|23-Aug-2005 12:56:36 EEST
|JSPWiki version|2.2.28
|[Idea Category]|GenericIdea
|[Idea Status]|NewIdea

I have previously used TWiki and I prefer the way it handles multiple sequential saves by the same user:

Within a given timeframe (default 1 hour, should be definable as a property) multiple saves by the same user overwrite each other without creating new versions. 

That is: the first save always creates a new version and backs up the previous version. The following saves first check: is user same, and is current save time less than an hour away from previous update. If so, no new version is created and the page text and the modification date are directly overwritten.


Often a page is saved and when seeing the result yet another point is detected or something forgotten is remembered. This frequently leads to multiple minor edits following a major edit.

This feature is not intended to save disk space, it is highly useful to make the revision control and comparison feature more useful, because minor are already compacted.


We have changed the jdbc provider to achieve this and it required only a handful lines of code in updatePageText. Is this more complicated with the file-system providers?

See also [Idea Save And Continue Editing] which may be covered by this.



This maybe be difficult to handle in a conflict situation.  But it's certainly worth considering.

-- JanneJalkanen


One thing that immediately comes to mind is this scenario: someone spends say, 59 minutes editing a page, in multiple sessions. In that last minute they accidentally delete a substantial portion of the page and click on the Save button.  In the current situation, they could just go back to the last revision, but it ''seems'' that in your proposal they would lose the entire hour's work. I'm not sure I'd even want this as an option, honestly. I don't mind the disk space, and having multiple revisions of a page during an editing session might be considered by some to be a Very Good Thing. As a writer, I might like a paragraph I had deleted twenty minutes ago, and currently I can recover that if I'd saved it. Revision control is a godsend. Perhaps I'm not understanding your proposal correctly — are the minor revisions created by a single user during that hour also stored in some way, or after one hour is there just one stored, recoverable revision?

-- MurrayAltheim


In regard to Janne's point: Can you explain a scenario where it would not work in a conflict situation (users A and B):

A saves\\
A continues to edit\\
A saves within 1 hour\\
-> Result is one version

A saves\\
A continues to edit\\
B starts to edit\\
B saves\\
A saves within 1 hour\\
-> Result is three versions (A B A)

With regard to Murray: The proposal does involve some tradeoff. However, the major problem when actually using any wiki to collaboratively develop content is to understand what is new and what has been updated or added by others. Thus in my experience, the Diff function is one of the central points. Having all versions is theoretically sufficient, but if in practice it becomes too cumbersome to understand which versions are actually the relevant and to follow the updates, the usability suffers.

I propose to introduce a property in the properties file, called something like: {{{NoVersioningSaveBySameAuthorIntervalMinutes}}} or something much better named. Setting this to 60 would create a 60 minute time span, setting it to zero would recreate the current behavior (any save is considered a new version and can be compared with diff functions). So nobody would have to make the same choice between usability and perfect change tracking. 

-- Gregor


Gregor:  if setting the property to zero reproduces the current situation, I certainly have no problem with it, and we might investigate setting it to 60 minutes to see the impact. We're currently in a prototyping mode right now, so if things are a bit unstable, our ''bleeding edge'' users won't mind so much. It's after our director begins using the wiki that we have to be more cautious... -- MurrayAltheim