Quote from: OpenGeek at Jan 09, 2007, 05:31 PM
[*] Revisions to Content are stored incrementally only; the baseline Revision is the only full copy.
[*] Rollback of Revisions consists of reconstructing a specific Revision by patching from the baseline with the relevant incremental diffs.
[*] Archiving of Revisions will be possible by exporting up to a specific Revision, and resetting the baseline at the next Revision. Where and how it is exported will be completely independent and configurable.
I look forward to all of this (actually, I’m drooling).
I hope this strategy can also be leveraged to simplify staging from a test site.
Once the revision engine is working, it should be possible to let users make changes to a localhost or other test site, generate a diff, then upload the diff to the "real" site and use a utility to upgrade the site (or let the upgrade utility use the local diff file). But then, you guys are probably way ahead of me on this.
Right now, it’s really tough to do staging since it’s hard to be sure about the extent of the ripple effect when you make a number of changes to a local site It’s a pain to FTP the entire site and export/import the whold MODx database just to be sure. (If anyone has a good solution for this that I haven’t discovered, don’t hold back).
Bob
Hello,
newbie to MODx, novice to AJAX, CSS, fluent in HTML, PHP, Perl, C++, C, ..., FORTRAN, PASCAL, ...
Just a thought on versioning, based on experience in various Source Code Control (SCC) systems.
There are three basic structures for storing the base and the revisions.
0: all version kept in individual records
extract the desired version
[ used mostly for binary files where a "difference" isn’t really meaningful ]
1: base line is original version.
deltas from previous version to next version.
start from base line and apply deltas until the desired version is achieved.
2: base line is most recent version
deltas from next version to previous version.
start from base line and apply deltas until the desired version is achieved.
The difference is in which end of the queue will be wanted most often - the original or the most recent.
There are SCC systems out there that do it both ways (0+1 and 0+2), and provide excellent service to their customers/users. For example, I believe that RCS and SCCS make opposite choices.
So it is really a matter of choice and preference, not functionality at the end of the day.
Just mentioning it as I didn’t see mention of this variable in how the core team addresses versions and thought you should at least think about the choices. ( Presuming you haven’t already and just didn’t think we needed to know or care about the answer, which we probably don’t. ;-)
-Jesse
