Tags:
archive_me1Add my vote for this tag create new tag
, view all tags

Avoid Consecutive Revisions by Same User

TWikiHistory has this:

  • 09 Feb 1999 - TWiki:Main.PeterThoeny
    • No new topic revision is created if the same person saves a topic again within one hour.

Many people go back in the browser to make more changes, or after a few minutes hit edit again to add/change content. This feature works transparently in the background, the user does not need to be aware of it (same as with revision control)

There are voices that this it not common CM practice to massage the top revision of a topic (technically it is a remove top revision and add a new one), but TWiki edit works differently from CM: For source code you keep a private copy of all source, do tests, and once satisfied, check it into the repository. TWiki edit is direct, it hides version control by design for KISS.

At my workplace I got feedback that this feature is nice since you do not need to worry about repeated quick edits.

This is a unique feature of TWiki among Wikis and should be retained.

-- PeterThoeny - 31 Oct 2004

I said the following in ReleaseLocksOnSave (slightly edited here for clarity):

I just thought of a time where being able to see every revision would have helped me out.

However I wouldn't normally want to see every trivial revision by the same author. Perhaps rdiff needs a collapse=sameauthor url parameter that would show a view that merges revisions by the same author within a configurable time period.

I'd also like to see a history page for topics showing every diff and allowing direct comparisons beween any two revisions using a collapse=all parameter that would collapse all revisions into a single diff regardless of author.

-- SamHasler - 31 Oct 2004

i would prefer that this handy feature be retained at the UI level, rather than at the Store level.

there are times when i definitely don't want consecutive revisions merged. for example, several times when i have refactored a topic, i would perform several edits on the theory that if one of the refactors turned out to be too radical, there would be an intermediate version which i could roll back to. this is not possible if consecutive revisions are always merged.

(i think it's premature for voting; put the poll back if you disagree ( this is a wiki wink ) )

-- WillNorris - 31 Oct 2004

It'd be nice if consecutive changes by the same author were somehow lesser - and not shown. Sometimes I like the feature, but on several sites I've turned it off. Perhaps we could use 1.x.N revisions for subsequent minor edits.

Fair enough about the poll - its only there to challenge assumption. My thought was that we could modify the poll as we go through, (it would now be questioning 1) is the feature a good idea, 2) is the current implementation right).

-- MartinCleaver - 31 Oct 2004

As Will said, there are times where you want a new revision before the one hour window is up. A ForceNewRevisionCheckBox can do that.

Collapsing revisions just on the UI would be possible but it is not KISS. It does not avoid needless revisions though, they will be visible if accessed by other means such as WebDAVPlugin.

-- PeterThoeny - 31 Oct 2004

ForceNewRevisionCheckBox relies on users remembering to use it and there would be times when it was not used when it would have been helpful to do so, not necessarily just to the user doing the editing but to other users who will view it later. I wouldn't want to rely on other users remembering to use the feature when it would benefit me.

If every revision was saved and it is possable to view collapsed diffs of all diffs at the UI level then you get the best of both worlds. You can view collapsed diffs by default but you always have the option to view the the expanded diffs when they are helpful.

-- SamHasler - 31 Oct 2004

Could this be tied to the "release edit lock" flag? If the user keeps the flag, he or she intends to continue editing, and these revisions should be merged into a single revision. If the user releases the flag, that is an indication that he or she is done and if the user continues editing (even within the time window), a new revision is created.

-- ThomasWeigert - 01 Nov 2004

No. There are times when you would want to create a new revision and continue editing, and others where you might want to merge revsions (when viewed) and stop editing.

-- SamHasler - 01 Nov 2004

I understand, and now agree with, Peter's point on the revision collapsing being KISS. Assuming we go with ReleaseLocksOnSave, the "release edit lock" flag is no longer relevant (locks are only held for the duration of the atomic checkin operation), so I removed it in this version. So, it seems that adding in a "force new revision" checkbox would not clutter the UI any more than it already is cluttered.

Questions

  1. Given that contributions are dated, not timed, doesn't it make sense to concatenate if the new rev was made the same day? (i.e. if the date in a signature would be the same in both revisions). The 1 hour limit is an artifact of the old implementation, but this time limit can now be much smarter...
  2. Should forcenewrevision be supported on both topics and attachments?

Here's the spec as I reverse-engineer it from the code:

  1. A second revision made by the same user will be concatenated onto the previous revision, if made within one elapsed hour.
  2. The second revision resets the timer, so a sequence of revisions 59 minutes 59 seconds apart will concatenate to a single revision.
  3. Revision collapsing is only supported on topics, not attachments.
And here's my proposed revision to the spec (compatible with WillNorris' ForceNewRevisionCheckBox patch):
  1. A second revision made by the same user will be concatenated onto the previous revision, if made on the same date, where "the same date" is defined as the date that would be put on a signature.
  2. Revision collapsing is supported on both topics and attachments.
  3. A new revision can be forced by setting the forcenewrevision parameter to the save (attach, upload) script to a non-zero perl boolean value (i.e. anything but 0 or whitespace). This will give the same behaviour as if a different user were checking in. The forcerev parameter defaults to a zero value.
  4. If the underlying Store implementation cannot support the collapsing of revisions (e.g. it is based on subversion), it may ignore the forcenewrevision parameter.
  5. edit, preview, upload and attach templates will have a "force revision" checkbox that may be selected to force a new revision.
I do not propose to support revision suppression for attachments in the UI screens, only in the Store. If someone else wants to do the UI work they are welcome.

As well as passing the forcenewrevision parameter to the appropriate Store functions I will also add the following function to the Store API:

---++ sub getFeatureSet() => ref to a hash of optional feature names.
Available features are mapped to 1.

Usage:
<verbatim>
    my $features = TWiki::Store::getFeatureSet();
    if ( $features->{delrev} ) {
</verbatim>
Optional features currently available are delrev and forcenewrevision The idea is to provide a simple interface for the UI to query to determine the feature set provided by the Store, so that appropriate options are presented to the user.

-- CrawfordCurrie - 01 Nov 2004

Thanks CrawfordCurrie for that great proposal! One thing that should stay is the time difference which decides if this is going to be a new revision. Depending on the same day is rather long and does not consider people working during midnight(?). I would like to see a defineable time which is sliding beside the edit process and gets extended every time you edit the object (like it was with the old behaviour).

-- AndreUlrich - 01 Nov 2004

One thing that hasn't been mentioned - the BIG #1 reason for consecutive revisions by the same user -- or is it glaringly obvious?

Fixing small typos and spelling mistakes!

As far as I'm concerned that's a good reason. There seems to be a fundamental law of the universe that no matter how well you proof-read some typo always gets in. Publishers tell me that the more important the publication the more persisitent that final typo is.

-- AntonAylward - 01 Nov 2004

Crawford's proposal sounds very good to me.

One question though, what happens with serial TWikiGuest edits?

-- MattWilkie - 02 Nov 2004

Current spec:

  • No new revision is created for edit and attach within $TWiki::editLockTime (default one hour)
  • Editlock time window shifts each time user does an edit, preview, save or attach
  • repRev gets logged in the TWiki log for both, user save within window and admin repRev, respectively

I find the configurable time limit more useful then "the same date". As Anton points out, the same topic tends to get edited frequently within a short time frame to massage and beautify the content. After a lunch break or a meeting people usually intend to work on additonal content, rather then fixing the previous one.

Crawford's spec looks good to me. On the other hand, why fix something that ain't broke? There are many other features and enhancements that promise higher yields smile

-- PeterThoeny - 02 Nov 2004

ATM serial TWikiGuest edits will be merged, though we can easily put in a filter to force a new revision for this special user.

AFAICT a new revision is created for attachments, even if uploaded within an hour.

Erm Peter, something that ain't broke? You are saying that the current locking model isn't broken? So you don't want ReleaseLocksOnSave in Dakar? I'm confused...

-- CrawfordCurrie - 02 Nov 2004

New rev for attachments: This is not the case, at least not for the latest production and the latest MainBranch. I tested it yesterday on TWiki.org.

Ain't broke: Different case if the current repRev functionality prevents the ReleaseLocksOnSave implementation. Is this the case? Or is it a "want to reimplement at the same time because it is convenient" thing?

-- PeterThoeny - 02 Nov 2004

FYI, I think this feature "Avoid Consecutive Revisions by Same User" is really bringing only trouble, confuse users, and provokes loss of data. I do not care changing its spec as long as we can still disable it via $doKeepRevIfEditLock = "0";

If you still want this feature, I advise not to try to make TWiki behave intelligently (which it cant): just check in all revisions, and allow refactoring afterwards by a web page listing revisions and allowing to collapse them (via rcs -o), maybe restrincting this functionality to admins and authors of the revisions to be removed.

-- ColasNahaboo - 08 Feb 2005

Edit | Attach | Watch | Print version | History: r18 < r17 < r16 < r15 < r14 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r18 - 2005-02-08 - ColasNahaboo
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.