1
ajaxbr
Version control?
  • 2004/11/23 2:43

  • ajaxbr

  • Quite a regular

  • Posts: 276

  • Since: 2003/10/25


Hi all,
I've started this topic to discuss whether Version Control is/should be in XOOPS development roadmap. More specifically, should a Version Control system be integrated into the core?

What kinds of modules/applications would benefit from a good Version Control in XOOPS? Is there any major drawback of using this kind of system (like being harder to really delete bad data)? What benefits* would you expect/demand from this?


*my main expected benefit: if you delete something or perform a really bad edit (be it news, links, whatever), an "undo" would be great. Secondary: when I write a large piece of text then slim it down to focus at a single topic, I lose all the related-but-off-toppic info that was there in my draft

2
ackbarr
Re: Version control?

IMO, since what constitutes as 1 version of an element differs from 1 module to another (a news article should store certain fields, an FAQ article should store others), this really is a feature that the module should be responsible for implementing. Other features currently in the core have a base commonality (see comments, notifications, blocks, etc).

3
ajaxbr
Re: Version control?
  • 2004/11/23 12:03

  • ajaxbr

  • Quite a regular

  • Posts: 276

  • Since: 2003/10/25


Hi, ackbarr
IMO it would only make sense at DB level, as a core feature that can be used at will by module developers.

Version control would be used primarily for text content, but could be integrated in $xoopsDB, which is as a common base as it gets. A core class would make it possible, if module developers wish to, to set a given field as VC-able and then everything that make a good VC system would fit in (not that these have to be there): history, check-in/out, diffs, branching, locks, etc.

If it's a good OO solution, it can be used to VC settings, blocks, templates, etc., according to module developers' clever use of the class

As things are today, backups and stand-alone text documents (preferably VC-able, like in OpenOffice and MSOffice) are the only tools for keeping your content safe and to work with drafts/revision/etc. And if a module developer solves this issue, other will have to reinvent the wheel... IMO it's a common base.

4
ajaxbr
Re: Version control?
  • 2004/11/23 20:56

  • ajaxbr

  • Quite a regular

  • Posts: 276

  • Since: 2003/10/25


Proposed lame implementation (in ugly pseudocode ):

New core function: xoopsDb->vcsinsert
**Module developers can call it right before each $xoopsDB->query($sql);, uses the same $sql variable that will be used for updating or deleting data.
function vcsinsert() {
     if (
ereg("DELETE FROM"$sql)) {    //Is it a DELETE query?

    
$sqlvcs_sel str_replace("DELETE""SELECT *"$sql);
    
$result $xoopsDB->query($sqlvcs_sel);
    
$vcsdatabase64_encode(serialize($result));
    
$vcsinsert"INSERT INTO ´xoops_vcs´ (`vcs_id`,`vcs_content`,`vcsdate`) VALUES (´".$vcsid."´, ´".$vcsdata."´, ´somedate´)";
    
$xoopsDB->query($vcsinsert);
}
      
      elseif (
eregi("UPDATE [:print:]* SET"$sql)) { //Is it an UPDATE query?

      
$sv_sel str_replace("SET [:print:]* WHERE"""$sql);
      
$sqlvcs_sel str_replace("UPDATE""SELECT * FROM"$sql);
    
$result $xoopsDB->query($sqlvcs_sel);
    
$vcsdatabase64_encode(serialize($result));
    
$vcsinsert"INSERT INTO ´xoops_vcs´ (`vcs_id`,`vcs_content`,`vcsdate`) VALUES (´".$vcsid."´, ´".$vcsdata."´, ´somedate´)";
    
$xoopsDB->query($vcsinsert);
      }

     else {echo 
"The VCS has found an error and borked like totally";}
There. The old data is lamely saved, regardless of table structure, for mod developers to retrieve when needed.

AFAICS i's well implemented in the Version Control Class and something similar could be added to the core without affecting anything that doesn't ask for a backup/old version/undo query. Opinions?

Login

Who's Online

175 user(s) are online (128 user(s) are browsing Support Forums)


Members: 0


Guests: 175


more...

Donat-O-Meter

Stats
Goal: $100.00
Due Date: Apr 30
Gross Amount: $0.00
Net Balance: $0.00
Left to go: $100.00
Make donations with PayPal!

Latest GitHub Commits