You'd be amazed how many don't understand Differential or Incremental ![;)]( "Wink")
. Or, the difference between 'incremental' (small 'i') and 'Incremental' (capital 'I'), whereby the former is an adjective, and the latter refers to a mode/method (implying dynamic/rotating storage is also used) ![:)]( "Smile")
Anyway, the disadvantage of Versioning is the cherry-picking required to achieve mass rollback (so that, while possible, it's generally not practical). For a file or three after an isolated accident, it's fine - plus, you get a 'clean' full Restore by default, even while panicking (which is not a good time to be doing multiple/complex procedures...).
Otherwise, it stores only one copy of any single captured change, and can even be 'turned down a notch' on the fly if space becomes tight - without re-designing an Incremental schema (changing variables used, interval/scheduling, etc). It has separate number and duration settings for increased flexibility. Note that if these 'collide', [how many] trumps [how long], so if you have it set to keep [3] Versions for [30 days], but edit a file daily (and run the profile / capture the edits daily also) then in ~4 days time, you'll have 3 Versions each less than a week old...the [30 days] setting is never reached (and is thus not observed)
Versioning also captures deletions (which we just treat as a fairly drastic change). Naturally, if deletion is all that ever happens to a file, there'll normally only be [1] of them needs keeping, but it may have been edited prior to that, in which case higher number/duration settings might be advisable. It's entirely up to the user to design his own scheme, based on his (or his users') change-patterns, fallibility, whatever.
. Or, the difference between 'incremental' (small 'i') and 'Incremental' (capital 'I'), whereby the former is an adjective, and the latter refers to a mode/method (implying dynamic/rotating storage is also used) 
Anyway, the disadvantage of Versioning is the cherry-picking required to achieve mass rollback (so that, while possible, it's generally not practical). For a file or three after an isolated accident, it's fine - plus, you get a 'clean' full Restore by default, even while panicking (which is not a good time to be doing multiple/complex procedures...).
Otherwise, it stores only one copy of any single captured change, and can even be 'turned down a notch' on the fly if space becomes tight - without re-designing an Incremental schema (changing variables used, interval/scheduling, etc). It has separate number and duration settings for increased flexibility. Note that if these 'collide', [how many] trumps [how long], so if you have it set to keep [3] Versions for [30 days], but edit a file daily (and run the profile / capture the edits daily also) then in ~4 days time, you'll have 3 Versions each less than a week old...the [30 days] setting is never reached (and is thus not observed)
Versioning also captures deletions (which we just treat as a fairly drastic change). Naturally, if deletion is all that ever happens to a file, there'll normally only be [1] of them needs keeping, but it may have been edited prior to that, in which case higher number/duration settings might be advisable. It's entirely up to the user to design his own scheme, based on his (or his users') change-patterns, fallibility, whatever.