Implementing article revision history for Java based web application

Question

Any ideas of how best i can implement article revision history for a Java based web application and save it in AuditLog

StackOverflow already has such a feature allowing one to see the differences from one version to another, almost like SVN clients.

This is more of a design than implementation question.

addition: How would one display these changes on the web page?

addition: Proposed solution

Article
--------------------------------
    Integer id
    String title
    String body
    List<Tag> tags
    AppUser createdBy
    Date createdDate

AuditLog
--------------------------------
    Integer id
    Integer objectId
    Operation operation // enum with UPDATE and DELETE. I won't audit an insert
    Date createdDate
    AppUser createdBy
    String class
    String revisionXML
    String comment

A Hibernate Interceptor will intercept the save process and use Castor XML to create an XML string of the old object.

The class and id is used to get the revisions of a particular object.

google-diff-match-patch will be used for creating HTML diff files

Answer 1

The best solution would be to use a database or storage which already supports versions, for example Apache Jackrabbit.

If that's not an option, then you must decide where you want to store the articles. On the file system? Then make each article a directory and save the revisions as numbers (00001, 00002, etc.) and put the number of the last revision in a special file (like current). Then you can quickly find out how many versions there are (just look into current) and go forward and back.

If you use a database, then add a version number field to the article table and add a second table or a flag which says which one the current version is. You could also select with max(version) but those SQL constructs tend to be pretty ugly and confusing. It's much more simple to save this information elsewhere.

[EDIT] To generate diffs, look at this project: google-diff-match-patch

Answer 2

I would use an existing VCS (for instance, SVN) under the hood. There you have the revision history - all that's left to make is an interface from your app to the VCS.