It would be very interesting to be keep a version history for Notices/Slips. I imagine there must be lots of libraries that curse saving a new version of a Notice/Slip only to realise that they've horribly broken it? It would be especially useful with bug 11583
Sounds like holding the nocites and slips in a `git` would be a nice idea. One could then use the perl-apis to populate the db from there. I implemented a similar procedure for our automatic setup in j2k.
Could we update the notices log to use the diff Kyle added and then somehow use that to recreate/rollback?
(In reply to Alexander Wagner from comment #1) > Sounds like holding the nocites and slips in a `git` would be a nice idea. > One could then use the perl-apis to populate the db from there. I > implemented a similar procedure for our automatic setup in j2k. I think adding another dependency and moving part might be overkill in this case.
(In reply to Lisette Scheer from comment #2) > Could we update the notices log to use the diff Kyle added and then somehow > use that to recreate/rollback? I'm not familiar with the diff, but I was pondering a bit about the action_logs. For each notice, we'd want to quickly and easily be able to see how many revisions there were for a notice. For that, I think we'd need a table in itself. But in theory that table could point to the action_logs.
(In reply to David Cook from comment #3) > (In reply to Alexander Wagner from comment #1) > > Sounds like holding the nocites and slips in a `git` would be a nice idea. > > One could then use the perl-apis to populate the db from there. I > > implemented a similar procedure for our automatic setup in j2k. > > I think adding another dependency and moving part might be overkill in this > case. Well, IMHO it would be a very generic dependency (not sure if one even has to `apt get` it manually these days) and allow for a very generic solution generally applicable that might come in handy at various other locations probably some not yet on the radar. But of course there are other ways to handle diffs.
We do have a ReportsLog that is quite nice and could serve as a possible example. The action logs also allow to copare and see diffs. And we can now store JSON diffs as well. I think maybe this could be solved with what we already use in other places.