Re: [Phpwiki-talk] New PhpWiki on Sourceforge

[Steve W. <sw...@wc...>]

On Mon, 3 Jul 2000, Jeff Dairiki wrote:

> I just checked a new wiki_diff.php3 into the CVS repo.  It's faster
> than the previous one (which did turn out to be an issue.)  Also I've
> added the compose() (and reverse()) method to class WikiDiff, so it's all
> ready to be used in a full versioning system.

Great work! :-)
 
> "All" that needs to be done now is to fix the db access API and schema so
> that multiple backup versions can be saved.  I can work on that (particularly
> for the MySQL and DBM drivers) if I'm not stepping on any toes.

Not at all. I think that when a project stops refactoring code because the
developer whose code gets changed throws tantrums is the day that project
dies. Always feel free to question design choices; I do :-)

For the record I also want total versioning down to the first version.
However the point I differ on (my personal opinion) is that storage space
is cheap, Wikis are just text, so why not save the whole thing? Not every
little edit change though. Let me explain.

Right now we have a store of live pages and a store of their last version. 
When a new author saves the page the new version goes live, the current
live page goes into the archive, and the last version is lost forever.

What if the last version is not lost, but stays in the archive? We have
all the previous versions by the previous authors; little edits the
current author makes don't get archived (I know when I edit a Wiki page I
make at least two saves and usually more). How much room does this take
up?

A fairly long page on c2.com is http://c2.com/cgi-bin/wiki?LordOfTheFlies.
It's 14234 according to Netscape. Let's say the page is very active, and
there are 100 edits over its lifetime... that's over a meg of data. That's
probably a worst case senario; most pages don't see that much activity.

Another good yard stick is Ari's Wiki. It's using 23 megs right now, and
because DBM files keep every copy they ever had, and Ari's wiki is
*really* active, I think that's pretty good in terms of space (sadly, all
previous versions are lost in the DBM file).

Now, how much work is it to:

* Store only the diffs of the pages
* Recombine them when someone wants to see the differences between version
1.1 and version 1.99?

If it's not much work at all (on the programmer (Jeff :-) and the server) 
then I think only storing diffs is a Good Thing. If 50-100 megs for a Wiki
sounds accessive, storing only diffs is a Good Thing. If the problem is
also one that simply interests you and you don't care what benefit it has
for PhpWiki it's also probably a Good Thing (for you :-) 

I think we can stick with the "archive" table for this and the user will
see no changes in behavior, other than being able to retrieve any
previos version of the page.

I am going to go into this more in a separate post, but first I have to
check with my friends to see if we are still going to see the fireworks. I
had jury duty last week and took one of my favorite Wiki idea books along,
Jon Udell's "Practical Internet Groupware." (See my review at
http://www.amazon.com/exec/obidos/ASIN/1565925378/qid%3D962757399/104-0556265-3752700) 
. It gave me an epiphany regarding saving versions...

sw

p.s. my other favorite idea book is Philip and Alex's Guide to Web
Publishing, which is more of an opinion book than a technical book:
http://www.amazon.com/exec/obidos/ASIN/1558605347/qid%3D962757580/104-0556265-3752700

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain