views:

73

answers:

3

Hello,

idea

I would like to create a little app for myself to store ideas (the thing is - I want it to do MY WAY)

database

I'm thinking going simple:

id       - unique id of revision in database
text_id  - identification number of text
rev_id   - number of revision
flags    - various purposes - expl. later
title    - self expl.
desc     - description
text     - self expl

.

  • flags - if I (i.e.) add flag rb;65, instead of storing whole text, I just said, that whenever I ask for latest revision, I go again in DB and check revision 65

Question: Is this setup the best? Is it better to store the diff, or whole text (i know, space is cheap...)? Does that revision flag make sense (wouldn't it be better to just copy text - more disk space, but less db and php processing.

php

I'm thinking, that I'll go with PEAR here. Although main point is to open-edit-save, possiblity to view revisions can't be that hard to program and can be life-saver in certain situations (good ideas got deleted, saving wrong version, etc...).

However, I've never used PEAR in a long-time or full-project relationship, however, brief encounters in my previous experience left rather bad feeling - as I remember, it was too difficult to implement, slow and humongous to play with, so I don't know, if there's anything better.

Update: It seems, that there are more text diff pre-made libraries, some even more light-weight than PEAR, so I'll have to dig into it, probably.

why?

Although there are bazillions of various time/project/idea management tools, everything lacks something for me, whether it's sharing with users, syncing on more PCs, time-tracking, project management... And I believe, that this text diff webapp will be for internal use with various different tools later. So if you know any good and nice-UI-having project management app with support for text-heavy usage, just let me know, so I'll save my time for something better than redesigning the weel.

A: 

here is a php diff function : http://paulbutler.org/archives/a-simple-diff-algorithm-in-php/

and here is another: holomind.de/phpnet/diff.php

Ysangkok
thanks :] . . .
Adam Kiss
+1  A: 

I think your question is just boiling down to the one line (If there's something else, let me know, and I'll add on):

Is it better to store the diff, or whole text (i know, space is cheap...)?

It's definitely better to store the whole text, unless you really need to save space. Viewing the text will be a much more common action than checking a diff, and if something has a lot of revisions it could be a significant process to "build" the text for the latest one. Imagine a heavily-used page where you've done thousands of revisions, and the "whole text" is only stored with the original. Then you have to process thousands of diffs just to view the latest text, instead of just pulling it straight out of the database.

If you want to compromise, every time you calculate a diff between any two revisions, store it in a separate table. Then you only have to calculate any given diff once, so it'll be instant the next time you view the same diff. If necessary, this table could be pruned every once in a while to remove diffs that haven't been accessed in a long time.

Chad Birch
Isn't it also possible to build backwards from the latest version of a file?And another strategy would ofcourse be to save the versions that are most frequently viewed.
Niels Bom
That'd also be a good method, assuming that viewing older revisions is uncommon. One thing with that method is that calculating diffs between two older revisions takes extra steps. You have to build the two older revisions separately, and then diff them. If you store whole texts you can skip the whole building step. Again, just depends on how the system's being used.
Chad Birch
Okay, so let's say it's speed- and memory-wise to store whole text and "count" difference on comparing revisions, right?
Adam Kiss
A: 

If you're storing a lot of different versions of files git can help you quite a lot.

Niels Bom
Yes, but: either you have to have your own git-server our be ok with working on one PC (or, of course, paid git servers)
Adam Kiss
And by git-server you mean a server that runs git? If you have a virtual host you could do that, right? (Just interested)
Niels Bom
@Niels: yes, but I have most sites and client sites on *shared* server, unfortunately [for now...]
Adam Kiss