Re: [Phpwiki-talk] Towards reimplementing CVS

[Jeff D. <da...@da...>]

In message <Pin...@bo...>,Steve Wai
nstead writes:
>
>And that's when it struck me that if she posted the page to a newsgroup,
>that this was the same thing as doing a "commit" in CVS. And that's when I
>had my moment of "Aha! | Doh!"
>
>This is my vision for version control for PhpWiki: the ability to commit
>changes; the ability to retrieve any previous version. Not too difficult.

Here's my thoughts:

On how many archived pages to keep:
   Some wiki's may have storage space considerations, so I think there
   should be some way of configuring how many archived versions to keep.
 
   I definitely agree that all archived versions of a page should be
   accessible to everyone.

On what to archive:
   I think we all agree that we don't want to archive everything.  The
   question is how to filter out the small edits.

   When the author changes we should force the old version to be archived.
   This keeps competing authors from wiping each others work.

   So the question remains what to do when an author is editing his own work:

   Personally, there have been many times I've checked something into CVS
   (or some other version control system) when I've almost immediately
   discovered some braino and wanted to erase the checkin.

   I envision a check-box on the edit form labelled something like
   "This is a minor edit.  Do not archive previous version."  The default
   state of this button could be made to depend on the time since the
   last edit (if it's been awhile, the default would be to make a backup).

   To me it seems better to decide at edit time whether a change is "minor",
   than to try to guess whether the next change will be "minor".

   I suppose this is not incompatible with another checkbox labelled "commit",
   which would set a PRECIOUS bit in $pagehash['flags'].

Cool idea which just popped into head:

   Once the version history stuff is in place, must add 'diffs' link to
   RecentChanges entries.



>At this point I wanted to apologize to Jeff for what I think might have
>been a miscommunication. When we had this thread I posed a few questions
>to Jeff about doing diffs between versions: was storage an issue? Is doing
>a diff between version 2 and version 99 hard/expensive?
>
>Jeff, I think I might have scared you or intimidated you out of doing what
>you were working on... storing the diffs of pages. If I did I'm sorry. I
>was asking questions so we could discuss the possibilities, not to
>question your objectives. I'd like to revisit that discussion again.

No, no ... no apology needed, no offense taken, no problem!

I think your points are quite valid, and I think you have completely convinced 
me
that we should get version control working first; then maybe add the storing
of diffs.

Applying 100 patch sets to generate version N-100 may well get to be too
expensive.  It might be best (in the long run) to save small changes as
diffs, but save the whole page when large changes are made.


Not to worry, I'm still planning on working on the version control stuff,
but since this is going to involve changes to the database API, I've sort
of been waiting for a concensus to develop on how that's going to go.

Jeff