2003-05-14

Haven't really looked into other implementations, but would really like Subversion to be supported.

I'd say CVS is far more critical (and widespread) than Subversion. There are stable, widely tested CVS-Java modules around, too, so I guess the decision is a no-brainer.

As to good implementations on other Wikis, PHPWiki does it relatively well.

I would first use a version that works without CVS (only with the database backend). Most SnipSnap users are not able to install/maintain CVS.

The best I've seen is in Swiki. It automatically stores revision information for every entry and every uploaded file attachment as well! Wiki pages have a "revisions" action that shows you a visual diff between the current version and the previous, as well as options to diff between whatever versions you like. Each is also annotated with the author of the revision.

I used Swiki for project architecture and documentation on my last major project. The entire team was hooked on the revision feature; everyone constantly checked the "recent changes" page, and if something relevant to them changed they could then view the diff and determine what. This caught many documentation errors in and of itself, as the amount of information to be proofread was only what had changed. Sped up dissemenation of new information in long posts too.

You can download and install Swiki in just a few minutes. It is self contained like SnipSnap, and I believe it includes the Squeek runtime as well.

http://minnow.cc.gatech.edu/swiki

Actually you can check out the revision history on the Swiki Swiki itself and save a download. Try it on something like the Download page; the home page seems to have a lot of zero-change edits, probably from Wiki newbie error. From what I remember, the implementation artifacts looked a lot like XML-ized RCS files; one for the current page, and another file to the side with history information. I've never looked at the code itself.

I like these revision implementations:

• http://www.wikipedia.org/
• http://www.usemod.com/cgi-bin/wiki.pl

Some thoughts:

• include a comment field for when someone makes an edit. this comment shows up in the revision history
• the usemod method of radio buttons to select the two files to diff is a nice UI
• a revert button next to each revision would make restoration from vandalism or mistakes simple
• there should be some way to UN-ZAP a snip. perhaps a "trashbin" of zapped pages--after all, deleting a page is a kind of revision. (I had a student yesterday click on ZAP just to find out what it does. At a minimum, there should be a confirmation dialog. and is there a way to allow users to attach files, but not ZAP them?)

IMHO, subversion is the best way to go. It is a replacement for cvs, it handles binary content ,which cvs doesn't, and has a client API. Subversion also use WebDAV which is an extra.. The only downside is installation becomes harder. You can have versioning optional and that solves the problem of installation. WebDAV is an excellent protocol for CMS and snipsnap can benefit from it.

If snipsnap wants to build their own versioning system on top of a relational database, have a look at Redhat enterprise CMS

I think we have two conversations going here. Some of us are talking about a system that's visible to end-users for tracking changes to the snips. I.e. each time someone makes a change to a snip, the old version is saved. Users can go back and review the changes, including making diffs between versions. In other words, the features of an application level system for managing changes to each snip in the space.

Maybe I don't know enough about CVS, Subversion etc. and how they may apply, but I think others of you are talking about selecting a system for source code control for the underlying JAVA code in SnipSnap. Is that right?

Funzel, which was your question about?

It's unlikely we'll agree on any particular implementation (e.g., RCS, CVS, Subversion, database, etc.) as being "good" -- that's a subjective measure. But we can probably agree on the technical requirements for a repository, in general. For example, a minimal API might provide functions for:

• check-in
• check-out a specific version
• get the revision history

That should sufficient for higher level application features, i.e., show diffs, undo/revert/restore, etc. (Still some open questions, e.g., should there be revision history on comments?)

Personally, I think the big challenges rest in how diffs are viewed (e.g., colors, content, context) and what algorithm is used for comparison. I don't know how suitable it is for a Wiki, but some of the webtools at mozilla.org are nice. Examples:

cvsblame shows the line number, author, revision number, and content for each line.

cvsview gives a context diff with common lines against a white background, changed lines against a blue background, and unique lines against a green background.

It might be useful to have some SnipSnap.org style mockups to generate more ideas and discussion.

@pva: funzel is talking about revision control of snips.

@all: Thanks

As we have public SnipSnap CVS access for some time now, I was talking about a revision system for snips, you're right.

@robocoder: Yes, there is a API for revision management of snips that looks something like:

• storeVersion(Snip)
• loadVersion(Snip, Version)
• loadVersion(Snip, Date)
• loadLastVersion(Snip)
• getRevisionHistroy(Snip)

in something like a RevisionManager. This manager can then implement a backend like CVS, Subversion, Enabler, OODBMS or SQL.

• I would revision comments too
• Displaying diffs is another beast. What we need now is to add a [last] button to SnipSnap to undo changes

I think the main focus should be on the self contained aspect of SnipSnap. Adding CVS or subversion or what-ever is a bad idea since it requires that something else is installed as well.

Take subversion for instance: it is a pig to install. Agreed, it has a lot of merits but are you not trying to shoot mosquitos with a canon here? And the same applies to CVS and alikes.

What is needed is revision control, that is true, but what I am saying is that a full fledged version control system might be overkill.

A simple database should suffice since the aim is to retain previous versions, not be able to diff and merge everything. Just treat previous content as a binary unit and make no assumptions about content. Provide a mechanism to retrieve it with a URL. It is that simple.

The best thing with SnipSnap is that it runs "out of the box". Keep it that way, please.

@koenig What is the purpose of versioning if you can't roll back or diff two versions?

Yes. We will always deliver a self contained version of SnipSnap, this is our top design goal for SnipSnap.

@omoikane:

• support for a [last] button to undo changes
• then: diffs

Any ideas on the ETA for this ?

Soon, I'm currently working on this and full time when labels are finished.

Should

• Version
  
• VersionAuthor
  
• VersionDate
  
• CreatedDate
  
• Creator
  

be standard lable for all snips ?

Thanks for the suggestions, we currently want to get a feel for labels and take a look at SnipSnap, which currently hardcoded meta-data could / should be moved to labels.

As far as UI for displaying diffs and versions goes, Wikipedia is the best that I've seen.

Could I suggest that "zap!" be renamed. This is a very poor choice of label names, particularly for the American English-challenged. I too had a user today use the "zap!" link to see what it does, four times! with the side-bar portlet, index, and a couple of user-generated pages no less!

Is there any way to gain access to the mckoi database to resurrect a zapped page?