Proposal added to official ideas list at http://drupal.org/node/237619
The node_revisions table currently stores a full copy of everything for every revision.
For space considerations it would make a lot of sense to store it as diffs instead.
Many sites like drupal.org also have issues with simultaneous editing - using diffs might allow for merging of edits rather than the current locking system.
Note that in D7 core, node_revisions may well be handled similarly to CCK fields - so something extensible to both models is likely to have the most chance of future use.
This project would probably be implemented as a patch to core and/or cck module.
Modules which deal with revision related stuff already:
http://drupal.org/project/diff
http://drupal.org/project/revision_moderation
Difficulty:
Pretty hard.
Comments
I don't think this is a good
I don't think this is a good idea. Mainly because it is contrary to Drupal's design philosophy: We filter on output.
I DO think this is a good idea.
Firstly, because it would be awesome. Secondly, because you would be able to handle simultaneous editing much better than currently possible in Drupal, which would be awesome. Thirdly, I do not think this is contrary to Drupal's design philosophy at all. But we have to make clear that the diffs have to go backwards: e.g. diffing to the current version, not the oldest version, because that would be a huge performance drain.
I would be willing to mentor such a task.
drafts
We discussed this on irc and are thinking about changing the proposal to be about a draft (and maybe simultaneous editing?) system for Drupal rather than specifically diffs - which is more implementation specific. i.e. - what we want is drafts and live editing, not specifically diff storage. And killes expressed some rightful concerns about potentially lossiness from diffs. Would that still be awesome enough?
RE: "changing the proposal
RE: "changing the proposal to be about a draft (and maybe simultaneous editing?) system for Drupal" --
Drafts can be kludged in a few different ways -- for example, we have created a draft mode that sets the the node to "unpublished" and used workflow and workflow access to create a "Draft" state --
As I see it, drafts and simultaneous editing are related, but ultimately different issues. BTW -- I am defining "draft" as a unfinished post that the author saves, knowing they will return to it later, and "simultaneous editing as what people can do on Google docs.
With that said, you don't really need a "draft" state with Google docs because the app autosaves and autoupdates frequently -- so, if your simultaneous editing is good enough, you don't really need a draft mode.
With that said, how does Mediawiki solve this? Is there code there we could borrow?
And with all that said, I'd love to see a version of this project move forward -- currently the most advanced solution that addresses this is the checkout module -- this is a good start, but something of a stopgap measure.
FunnyMonkey
Tools for Teachers
FunnyMonkey
Prior art
http://drupal.org/node/50682 ;)
Not only is a great idea...
I thought Drupal already did it.
We were just getting around to this being a concern, as we get our arms around 5.7. Would this be only a 6.x mod?
Yes.
Yes, 6.x. 5.x will be supported for < 6 months after the end of SoC 2008, so it doesn't make sense to make it as a 5.x module. Besides which, 6.x is much more awesome than 5.x.
small nitpick on support timeframes
Assuming a spring 2009 release of Drupal7, Drupal6 will be supported for approximately 1 year and 6 months after the end of SoC 2008.
Drupal5: End of Life when Drupal7 is released in approximately Spring 2009 (0.5 years after end of SoC 2008)
Drupal6: End of life when Drupal8 is released roughly spring of 2010 (1.5 years after the end of SoC 2008)
This module could require core modifications which would mean that it couldn't really take off until it got included into Drupal8 (assuming feature freeze before the end of SoC). So, hopes for inclusion in Drupal5 seem inaccurate. Hopes for use under Drupal6 seem reasonable, though it may require a patch.
--
Open Prediction Markets | Drupal Dashboard
knaddison blog | Morris Animal Foundation
Revised proposal
Make node revisions more awesome through integration with SVN
Currently in Drupal, each revision of a node is left in the database. This project would be to write a contrib module to make the subversion RCS handle Drupal node revisions.
This project has two parts:
Mentors:
cwgordon7
Difficulty:
Pretty hard, but also potentially really awesome.
Database SVN done in a way (for test-live merging) by dbscripts
http://drupal.org/project/dbscripts - a new contribution by ceardach
benjamin, Agaric Design Collective
benjamin, agaric
This would be really sweet!
+1 for working on this and making it happen. SVN handling of node revisions would be a very valuable feature for Drupal! I wonder if any other cms systems or frameworks are doing this already.
--
Gravitek Labs
--
Gravitek Labs
Joining efforts
I think it's a nice idea.
Joining both ideas, with the proposed feature to make the use of diff's in the DB, maybe I can:
That functionallity would be usefull to make wikis with drupal better.
I hope you can help me to get the right direction.
That's correct
Right, I don't see Version Control API to do operations that require a working copy / checkout, which includes doing commit, branch/tag, or similar stuff programmatically.
What you did get wrong, though, is my nick. I don't have any relations to the popular sauce, apart from loving to decorate my noodles with it. So, please swap the "t" and the "s".
+1 :) I'm willing to wait
+1
:)
I'm willing to wait for this, especially since it obviously will result to performance improvements.
The Power of Drupal Categories
A Podcast for Mac Switchers
User Experience Design
A Podcast for Mac Switchers
I doubt that there would be
I doubt that there would be a big improvement.
New student proposal
I have sent a proposal described in:
Refactor Collaborative Editor
http://groups.drupal.org/node/10269
Add me to the list of people
Add me to the list of people who think this is pretty silly. There is a lack of depth to the argument for this (I refer to refactor node revisons to use version control as storage). Is that what is still proposed here?
Like catch mentioned before
Like catch mentioned before the proposal changed, so I post another discussion to avoid confusing :D.
My proposal is about refactor collaborative_editor module to allow better handling of simultaneous editing.
Revision Moderation
I think better simultaneous, collaborative editing is a great idea. But honestly, what drew me to this proposal most was the mention of Revision Moderation. I am desperate to see that functionality more fully developed and integrated into Drupal. The ability to have a single node exist in multiple states--one publicly visible and one (or more) in development, visible only to site maintainers--would be absolutely invaluable. See this feature request for a more detailed explanation and use case.