default maxNumberOfVersionsToKeep to something sane instead of infinity

[vangheem]

I'm sure this can cause crazy bloat on long running plone site. Bad default value IMO.

[hvelarde]

what would be a good value? 5? 3?

[vangheem]

I was thinking 20.

[alecpm]

Is this a real problem for any actual sites? Versions are only saved when content is edited by hand TTW, regardless how long the site may have been running. I would think people might be surprised to find that they start losing data after a certain number of edits.

[vangheem]

Most real sites have a few pages that are edited quite often. Storing every version forever seems like a bad idea.

Couple that with content types that also store image or file data and you can start seeing some real large bloat.

[alecpm]

Seems like a bad idea and is causing real problems for actual sites are different things though. If we promise versioning, that comes with expectations, no? If this is causing problems for real sites, then it's probably not a bad idea to put a default limit here, but otherwise why break expectations?

[vangheem]

as an alternative, if we have disagreement here, perhaps it'd be good to have this setting more prominently in Site Setup somewhere?

[alecpm]

Surfacing it somewhere probably makes a lot of sense. There's no versioning control panel, but I'm sure there's a semi-reasonable place for it somewhere.

[hvelarde]

I think @alecpm has a point here: this should be a decision of the integrator.

in my case I can tell you it is causing real problems but only on a few objects; I'm watching right now the sites of 2 customers and I can see one case on each site with an object with a crazy number of versions:

• site 1: object X has 3159 versions and is 2221978014 bytes in size
• site 2: object Y has 4473 versions and is 4075292072 bytes in size

this seems to be pointing to a hidden bug.

@vangheem 👍 on having it on a more prominent place and better documented; we also need to have an easier way to remove old versions without having to run an external script like this one: http://stackoverflow.com/a/9684696/644075

[vangheem]

@hvelarde in your case, perhaps disabling versioning for c.cover by default is the way to go also.

[alecpm]

Wow, that's a lot of versions :-) That script just calls the beforeSaveHook, so you shouldn't need to use it except to purge all content at once rather than whenever a new version is saved.

[hvelarde]

@vangheem I can't; the user expects to use the check-out/check-in feature to modify the front page. if I disable versioning, the feature is lot.

@alecpm do you have a better script to purge any object versions above maxNumberOfVersionsToKeep?

[vangheem]

@hvelarde check-in/checkout-out is different from versioning. check-in/check-out comes from plone.app.iterate.

[alecpm]

You don't need a script, just saving the content with a new version should trigger the purge. To purge all existing content, you need a script, but once the setting is set you shouldn't need it going forward.

I think versioning may need to be enabled on the type for iterate to work, but you don't need to enable the auto-version on save for that.

[hvelarde]

yes, versioning is needed for check-in/check-out; I discovered that yesterday when the client called me because the feature disappeared after I disabled it 🌵

[mauritsvanrees]

I have had an idea for a while to either change the default policy or create a new policy. The idea is to have two simultaneous limits:

• Keep last X revisions, default 10.
• Keep last Y days of changes, default 365.

What that should then mean is:

• Document A gets changed once a day. After a year this will reach its maximum of 365 revisions.
• Document B is changed once a year. After 10 years this will reach its maximum of 10 revisions.

So for fast changing content you can go at most a year back. And for slow changing content you can still get ten revisions back, even if that revision is ten years ago.

For existing sites we should probably not touch the settings during an upgrade.

[fulv]

Shouldn't there also be a hard ceiling? e.g. Document C is changed three
times a day. After a year this will reach 1095 revisions, but you should
be able to say the number is never to exceed 1000.

On Thu, Nov 17, 2016 at 11:33 AM Maurits van Rees [email protected]
wrote:

I have had an idea for a while to either change the default policy or
create a new policy. The idea is to have two simultaneous limits:

• Keep last X revisions, default 10.
• Keep last Y days of changes, default 365.

What that should then mean is:

• Document A gets changed once a day. After a year this will reach its
  maximum of 365 revisions.
• Document B is changed once a year. After 10 years this will reach
  its maximum of 10 revisions.

So for fast changing content you can go at most a year back. And for slow
changing content you can still get ten revisions back, even if that
revision is ten years ago.

For existing sites we should probably not touch the settings during an
upgrade.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#27 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcHxpDGuezgP7EMsStjxEb46d4msbxvks5q_KwkgaJpZM4FDu5p
.

[mauritsvanrees]

Yes, a hard ceiling may be good to. The current maximum field in the policy could be used for that. And the other 'soft' maximums could be new fields.

Note that I have no immediate plans to work on this, for now I just wanted to get the idea out. But on one Plone 3.3 site I did see this problem. After removing all revisions, the Data.fs went down from 40 GB to 4 GB.

[hvelarde]

in the Conference, @tschorr gave a lightning talk about collective.revisionmanager.

you must take a look on that also, as he said orphan revisions are left into the ZODB from time to time.