Ticket #599 (new enhancement)
Opened 10 months ago
|Reported by:||grin||Owned by:||armin|
For me it is probably the first thing I'd write in the design for a shared media to have full history. Granted, I'm quite an old user of Wikipedia and revision control systems, so it is natural that when more than one people involved I prefer not to leave on chance that nobody will make bad changes which go unnoticed for some time. So yes, I suggest to use a storage backend which supports: - storing all changes - ability to undo changes / revert version to a given checkpoint - ability to show differences / changes / changelogs
Since this functionality does not seem to be designed right now it'd be futile to expect you to rewrite everything for that. It is not impossible, however, to offload all of this to a storage backend, a plugin of sorts maybe (or rater preferably), which would communicate through a simple API.
infinote would request store, undo, difflog and revert requests from the API/backend, and the backend would translate this to the admin's favourite revision control system, may it be mercurial (my choice), git (the sado-maso-choice :)), subversion (for the conservatives) or cvs (for the lunatics).
Updates probably could happen in chunks, eg: - if only one people typing it'd flush every N seconds (say, N ~ 10) - if more than one people is typing it could flush immediately (too much load onthe backend) or flush rapidly (eg. 1-2 seconds).
If someone's lazy (khm I mean busy with other important things :)) this could be even done by calling external shell scripts with parameters. :-) Unless there are hundreds of people editing at once it wouldn't really use much resources as we humans are pretty slow.