views:

172

answers:

6

Rollback of an article


I have deleted a lot of the body of this question because I realised I should rephrase it. Here it the rephrase:

How can I implement something with strike throughs? Comparing one revision update to the previous. I don't want revision or version control per se, because I can just handle that in my mySQL database, but I want to be able to visually identify changes with green and red strike through updates on an almost changelog like page (should the user wish to see it).

I have seen something similar on the revision changes on SO, and would like to have something like this?

I think my question now is fundamentally different from the original, sorry

But here: http://stackoverflow.com/posts/2326658/revisions

+2  A: 

Your suggestion sounds entirely sensible to me: one table with a row per revision, and one table with a row per "displayable article" which effectively links to the current revision within the revisions table. What's verbose about that?

You could fake it with some sort of "current" column in a single table, but then you'd have to make sure that only one revision was current for any particular article, which sounds pretty nasty to me.

Jon Skeet
I think because I am also managing infinite number of language revisions also. It just seems to be quite a headful. What I have suggested above however, is the method which I use for managing my templates and it works fine. How would I go about doing something like on here with striketrhough for changes?
Laykes
@Laykes: do you mean that there maybe few versions of the same article in other (non-default) languages?
van
No, the languages is incidental. If I can do it with one language, I know I will be able to do what I want with multiple languages. I want to add a feature like on SO where you know what has been added and what has been deleted on each revision.
Laykes
A: 

Your question could be summarized as "how is version control implemented?" The usual is that each revision is stored as a diff from the old version instead of the whole text over again (though there are lots of variations). Most systems can/will store all the versions complete for non-text formats that they can't isolate changes into "lines".

Jerry Coffin
I don't think that would really be a realistic option. I am familiar with version control nd use git and svn daily, however, because the authors have the choice of using either markdown or TinyMCE HTML WYSIWYG editor, I think that doing a diff of the HTML it creates is mostly impossible. So, short answer, I probably can't do a diff on this.
Laykes
@Laykes:There's no question you *can* do a diff on it. The only question is how much that will save you. To do the strikethrough display you want, you pretty much *have* to do some sort of diff anyway.
Jerry Coffin
Jerry, how exactly would I do something like diff? I wouldn't actually know how to code this. (I'm a competant coder so I just need to know how, I would have thought substracting X from Y and strikethrough anything that is not left). Seems a little sluggish.
Laykes
@Laykes: the algorithms for diff are a bit much for a comment. The classic RCS diff is described in a paper by McIlroy and Hunt, at http://www.cs.dartmouth.edu/~doug/diff.ps. Of course, almost anything like SVN or Git will have source to one available as well. Offhand, it seems like you'd probably be better off using existing code than trying to write a new one...
Jerry Coffin
+1  A: 

Try storing it as an XML

As far as I can understand the problem. It can be solved if we store each line as a row. But that will be bad because number of rows increases tremendously.

So store data in a row as

<row num=1>How would you structure something like this. I want to allow my authors to create articles. However, </row>
<row num=2>should they choose, I would like to be able to allow each save to be a new revision and then allow each </row>
............

Everything in one row but in xml format. When u retrieve it, you can compare rows using num attribute.

RAHUL PRASAD
A: 
Pekka
+1  A: 

Part-1: data structure (from original question):

  1. One row per version -VS- all versions in one row:
    Store one revision per row, do not pack all revisions into one row as XML or any other multi-value supporting types. Initially the article might be edited few times and the revisions will be asked for by the author(s), but later on only the most recent version will be requested by your application. In this case there is no point in loading all the change history.

  2. One table -VS- two tables:
    Third_normal_form would suggest using 2 tables:
    - Article[ActicleID(int,PK), AuthorID(int,FK), ...]
    - ArticleRevisions[ArticleID(int,UK), RevisionID(int,UK), Content, RevisionComment, RevisionTimeStamp, ...]
    In any case store complete articles and do not play with delta-type implementation - your use case does not call for the complexity, but for simplicity. Also you might redundantly store the LatestRevisionID in the Article table for easier retrieval of latest revision.
    You might opt for the solution with one table. For an example look at line 76 (Table('wiki'...) in the database schema of Trac. Also you might take a look how Trac does it for its simple Wikis by looking at example of their revision history and revision diff, which are quite similar to those on StackOverflow.

Part-2: detecting and presenting differences between two revisions:
First of all, one does not visually identifies the changes, but rather programmatically. What you need is a library which given two files (strings/lists of strings) will provide you will a diff result. In many cases one opts for line-by-line comparison, as did stackoverflow). Then you need a mean of presenting those results to the use (with greens, reds, strikeouts etc).

Although I have little knowledge about PHP and its libraries, following links should get you started:

van
A: 

I can't tell whether you're dealing with diffs of code or more general documents. I did an implementation a few years back that displayed diffs of versions of wiki documents, with the two versions side by side, deletions marked in red on the older version, additions in green on the newer version. All this was done in javascript, first extracting just the text parts of the HTML, diffing those (using diff_match_patch.js), and then using the diff results to determine what to highlight (using styles to change background colors). It was pretty tricky, not perfect (but close enough) and involved quite a bit of DOM manipulation. So, doable, but not easy.

JST